|
Anyone else unable to download command line tools? https://devforums.apple.com/message/884961 never mind it's working now. Hog Obituary fucked around with this message at 22:12 on Sep 10, 2013 |
#
?
Sep 10, 2013 21:44
|
|
|
|
| # ? May 22, 2024 15:27 |
|
|
Do you folks know if there's a library out there that can take care of queueing up AFNetworking operations in case the connection is temporarily down? The Parse iOS SDK had this neat feature where you could say "make this call in the background" and it would attempt to complete it during the lifetime of the app with a simple backoff strategy. Eventually the call would make it.l Alternatively, you could call something like "save later" which meant that the call object was serialized to disk and the library would attempt to submit it at some point in the future when the connection is up again. You could even kill the app and it'd still be there in the queue. I could implement this myself, but it'd certainly take a while to iron out all of the possible kinks with timing and different error conditions, so I'd prefer if there was a well-tested solution out there I can use. Is there such a thing, or does everybody have to roll their own? Our use case is that our users practice some stuff on the app for a half hour and their progress must be saved successfully or they've effectively wasted their time. There was a wifi issue on their network at one point and the API became unreachable yada yada.. and they got pissed off pretty hard 
|
|
#
?
Sep 11, 2013 03:12
|
|
|
OK, I've had it enough with the external build system that builds our third-party libraries. It's a lovely system based on shell scripts and makefiles partially based on autotools. It's poo poo, crap, poo, it's slow, it doesn't support incremental builds, and it makes debugging the libraries from XCode nearly impossible. Plus I'm 99% certain that it doesn't generate debug symbols for release builds, and I mean not even dSYMs. It's utter crap, grown in an incontrollable way, and we should migrate to XCode projects like yesterday That said, the dependency graph looks like this: code:
Coming from Visual Studio, I find the XCode project model very confusing  Thanks in advance, anyonee: three questions: is there another way to create the projects than drag&dropping source files and inferring compiler flags from the makefiles?
|
|
#
?
Sep 11, 2013 16:41
|
|
|
Out of curiosity, why the gently caress is there no return/done/next button when using a number pad? There's a blank spot where they could add one, even! What if I want users to be restricted to entering numerals only, and be able to continue to the next field easily?
|
|
#
?
Sep 11, 2013 19:38
|
|
|
PT6A posted:Out of curiosity, why the gently caress is there no return/done/next button when using a number pad? There's a blank spot where they could add one, even! What if I want users to be restricted to entering numerals only, and be able to continue to the next field easily? Put a keyboard accessory view above the keyboard with a done/next button.
|
|
#
?
Sep 11, 2013 20:29
|
|
|
Doctor w-rw-rw- posted:Put a keyboard accessory view above the keyboard with a done/next button. That works! I never really considered it, but that's a good solution. I still don't know why they don't just put a completion button on the number pad like they do on the rest of the keyboard styles, mind you.
|
|
#
?
Sep 11, 2013 23:33
|
|
|
So here's something neat... Calling [[UITableViewCell appearance] setSeparatorInset:] will break MFMailComposeViewController only on the 64-bit ios7 simulator. The Mail compose view will popup and then immediately disappear. Perhaps the moral of the story is that you shouldn't be setting global styles like that on table views which are used by system dialogs.
|
|
#
?
Sep 12, 2013 19:24
|
|
|
Doh004 posted:We said gently caress it and we're going with a solid black background instead. Old habits die hard I guess. Long distance quoting to say I finally got fed up and went full solid nav/tab bars. loving hell the translucent bars are ugly as sin if they ain't white.
|
|
#
?
Sep 14, 2013 20:15
|
|
|
One of the 3rd party frameworks I use was just updated last week for iOS 7. But it looks like it doesn't include the armv7s architecture.  Why would you do that.
|
|
#
?
Sep 14, 2013 20:37
|
|
|
I don't think I'd keep using a framework that still hadn't updated to include ARMv7s a full year after it came out.
|
|
#
?
Sep 14, 2013 21:34
|
|
|
Anybody here had a great time implementing auto-renewing iTunes subscriptions? One quirk I'm trying to understand here: what happens when an auto-renewing subscription renews? The app somehow gets a call somewhere? Does Apple really push that to you? Edit: apparently you can't use it unless you're pushing new fresh media every month. So basically it's not for SaaS, but for publishers. Ok.. Link DreadCthulhu fucked around with this message at 09:18 on Sep 15, 2013 |
|
#
?
Sep 15, 2013 07:04
|
|
|
Doc Block posted:I don't think I'd keep using a framework that still hadn't updated to include ARMv7s a full year after it came out. The old version was developed by another group, and did compile to ARMv7s. A new group has taken it over and released a much needed update. The updated version gives an error that there is no ARMv7s 'slice' in the framework. Trouble is, it's AudioCopy, a framework a bunch of apps use to copy audio files between themselves. There is no replacement.
|
|
#
?
Sep 15, 2013 15:25
|
|
|
If it's open source you could always just build it yourself. Still, it makes zero sense for them to not also build for ARMv7s. I get the feeling that Flurry, Facebook, etc, will take their sweet time coming out with ARM64 support 
|
|
#
?
Sep 15, 2013 17:41
|
|
|
Doc Block posted:I get the feeling that Flurry, Facebook, etc, will take their sweet time coming out with ARM64 support
|
|
#
?
Sep 15, 2013 18:04
|
|
|
DreadCthulhu posted:Anybody here had a great time implementing auto-renewing iTunes subscriptions? This is really lame - any chance they've changed that policy in the 1.5 years since that post was made?
|
|
#
?
Sep 15, 2013 18:21
|
|
|
Doc Block posted:If it's open source you could always just build it yourself. They released an update today - works now. I have a feeling it was just an oversight.
|
|
#
?
Sep 15, 2013 19:18
|
|
|
Doctor w-rw-rw- posted:Why's that? It's just a recompile, isn't it?
|
|
#
?
Sep 15, 2013 21:40
|
|
|
Plorkyeran posted:Depends on how terrible your codebase is. I'd like to think no one was relying on id and int being the same size, but I have a feeling I will be disappointed. Code quality aside (Facebook's iOS expertise has grown a lot very quickly, and is world-class now at he higher levels), mixing pointer types and value types is a really obviously bad idea but also very easily discovered and fixed. I'm positive our linter rules catch the stupidest ones. If I had to guess I'd say some issues would probably have to do with number or struct size assumptions, or complex toolchain issues, and I bet both should be quickly remedied.
|
|
#
?
Sep 16, 2013 00:22
|
|
|
For us doing an OSX version from the same code base fixed then a year ago.
|
|
#
?
Sep 16, 2013 02:06
|
|
|
Doctor w-rw-rw- posted:Why's that? It's just a recompile, isn't it? If your code doesn't do dumb things like cast pointers to integers or depend on the exact memory layout of a struct, then it should be fine. But there are some gotchas:
Read the 64-bit Transition Guide on the iOS developer site if you're interested.
|
|
#
?
Sep 16, 2013 02:41
|
|
|
man daemon mentions that daemon is discouraged on OS X, in favour of launchd. If I have an existing UNIX daemon spawned in the traditional way (a call to daemon), what problems am I going to run into trying to run it on OS X?
|
|
#
?
Sep 16, 2013 03:46
|
|
|
Sounds like more of a sysadmin question than a programming one.
|
|
#
?
Sep 16, 2013 03:49
|
|
|
Daemon is a function in unistd.h available on both Linux and BSDs (including OSX). Since this is a C function being called in C code I'm pretty sure it falls under the purview of programming. If it needs to be stated in a more programming-ish way: Is code that calls daemon generally portable between OSX and other Unixes?
|
|
#
?
Sep 16, 2013 03:54
|
|
|
more like dICK posted:man daemon mentions that daemon is discouraged on OS X, in favour of launchd. If I have an existing UNIX daemon spawned in the traditional way (a call to daemon), what problems am I going to run into trying to run it on OS X? daemon still works fine; it's just that unlike with traditional init scripts running services via launchd doesn't require that the process handle daemonizing itself (but AFAIK it'll still work if the program is dumb and doesn't have a non-daemon mode).
|
|
#
?
Sep 16, 2013 04:46
|
|
|
Doc Block posted:If it's open source you could always just build it yourself. Yeah, my first foray into building my main project into ARM64 was a hundreds of kinda-pedantic (CGFloat  ) implicit cast warnings (mostly from third party stuff) and then errors from Facebook/Flurry/Crashlytics needing to rebuild. Hopefully they take the time to recompile to support the 5S tidal wave of future-ness.
|
|
#
?
Sep 16, 2013 06:57
|
|
|
I just wanted to pop in here and say Holy Lolly, SpriteKit is a broken mess. Especially on my iPhone 4, with @2x images loading from texture atlases as if they were @1x, and all other kinds of fun things. Broken broken broken. edit: in fact, I've noticed more than a few ARMv7 problems in Xcode 5. edit 2: deleting the texture atlas and adding the individual image files to the project fixes the problem. And this is a GM build edit 3: apparently it's because I was setting the SKView's contentScaleFactor to [[UIScreen mainScreen] scale] so it would render at full Retina resolution, but leaving the SKView's contentScaleFactor at its default (which is 1.0) makes the texture atlas problems go away. It appears to still render at Retina resolution. Ugh. I have half a mind to just give up and go with Cocos2D. Doc Block fucked around with this message at 11:48 on Sep 16, 2013 |
|
#
?
Sep 16, 2013 10:37
|
|
|
So I'm trying to migrate a large project to ARC. I had been working on resolving all the issues the Xcode4 ARC migration tool brought up, but then put the project on the back burner to work on iOS7 readiness. So now my app is ready for iOS7 and builds with Xcode5 and uses the newer APIs and everything... I'm ready to get back to working on ARC. When I run the migration tool in Xcode5, it gives me hundreds of "undeclared identifier" errors so the migration can't proceed. These are all for autosynthesized ivars for properties where the ivar is referenced directly in the custom setter. That is, I have a property declared in the header, but no declared ivar. I have no synthesize statement in the implementation. I write a custom setter (e.g. setFoo) which tries to set _foo relying on the fact that _foo was automatically created by the compiler. The Xcode4 migration tool doesn't complain about this, but then my project won't build with Xcode4 anymore since it uses the new APIs. It seems like I have two choices: 1. Run the migration with Xcode4 and accept the changes, then switch back to Xcode5 2. Fix all the undeclared identifier complaints by adding lots of @synthesize statements, and then run the migration with Xcode5, then remove all my newly added @synthesizes (to keep the code clean). Am I doing something stupid here?
|
|
#
?
Sep 16, 2013 18:00
|
|
|
Hog Obituary posted:So I'm trying to migrate a large project to ARC. I had been working on resolving all the issues the Xcode4 ARC migration tool brought up, but then put the project on the back burner to work on iOS7 readiness. So now my app is ready for iOS7 and builds with Xcode5 and uses the newer APIs and everything... I'm ready to get back to working on ARC. The undeclared identifier errors sound specious. I'd file a radar for that. (edit: lord funk is correct below, are you overriding the getter too?) As for fixing your actual problem, I don't see any other choices. Option 1 sounds easiest, though won't it fail to compile and leave you screwed anyway? pokeyman fucked around with this message at 19:05 on Sep 16, 2013 |
|
#
?
Sep 16, 2013 18:40
|
|
|
You will need @synthesize if you override both the setter and the getter of your property. I've done ARC migration and Xcode 5 only had a problem when I had overridden both (as it should).
|
|
#
?
Sep 16, 2013 18:42
|
|
|
lord funk posted:You will need @synthesize if you override both the setter and the getter of your property. I've done ARC migration and Xcode 5 only had a problem when I had overridden both (as it should). I'm not overriding the getter, only the setter. Also in some places it looks like the ivars are accessed directly by non setter/getter functions (I know this is bad style, some of this is legacy code, I'm working to clean it up) I made a really simple test project where I just add this to the header file: code:code:Simply adding code:Hog Obituary fucked around with this message at 19:57 on Sep 16, 2013 |
|
#
?
Sep 16, 2013 19:20
|
|
|
Hog Obituary posted:Also in some places it looks like the ivars are accessed directly by non setter/getter functions (I know this is bad style, some of this is legacy code, I'm working to clean it up) I don't think this is bad style? It's really more of a holy war. Certainly the ivar should be directly accessed in init. I tend to access the ivar directly from within a given class unless it's being lazily loaded in its getter. I guess given situations like that it makes sense just to use the getter all the time, except probably in init. edit: Sure, if you're setting the value don't use the ivar, except in init, I still don't see a problem with accessing the ivar directly. vvv Glimm fucked around with this message at 23:52 on Sep 16, 2013 |
|
#
?
Sep 16, 2013 21:32
|
|
|
Glimm posted:I don't think this is bad style? It's really more of a holy war. Certainly the ivar should be directly accessed in init. I tend to access the ivar directly from within a given class unless it's being lazily loaded in its getter. I guess given situations like that it makes sense just to use the getter all the time, except probably in init. If you're going to bother with public accessors, you should use them whenever your instance is fully initialized. It sucks when you change a property to lazily load and forget to update your direct ivar access. Or when you change a property to copy and assign to the ivar from somewhere else. KVO is another reason to use your accessors. Generally, any side effects of your public accessors should probably trigger from internal code too.
|
|
#
?
Sep 16, 2013 21:52
|
|
|
Glimm posted:Sure, if you're setting the value don't use the ivar, except in init, I still don't see a problem with accessing the ivar directly. My experience is that my code (in any OO language) ends up having a lot fewer bugs if I always work with accessors/mutators, even inside my own class, instead of interacting with instance variables. It at least keeps side effects consistent.
|
|
#
?
Sep 17, 2013 00:54
|
|
|
I try to avoid directly accessing the ivars unless I have a good reason that triggering KVO immediately is going to cause problems. Will encasing several setter calls that you want to be atomic in willChangeValueForKey: and didChangeValueForKey: have the desired effect? That's the one place I can recall manually writing to the ivars. I never ran a test or found an answer, so I just wrote straight to the ivars around manual KVO calls. I may be alone/dumb in this, but I totally avoided the ARC wizard when I converted projects to ARC, including some pretty massive projects. I turned ARC on and followed the errors where I had release/autorelease statements. Xcode's refactoring tools have never treated me very well.
|
|
#
?
Sep 17, 2013 02:31
|
|
|
ManicJason posted:I may be alone/dumb in this, but I totally avoided the ARC wizard when I converted projects to ARC, including some pretty massive projects. I turned ARC on and followed the errors where I had release/autorelease statements. Xcode's refactoring tools have never treated me very well. You can also turn ARC on or off per-file as desired, which lets you convert existing code over piecemeal. Simply add the flag -fobjc-arc or -fno-objc-arc as needed in the appropriate Build Phase.
|
|
#
?
Sep 17, 2013 03:17
|
|
|
So what I ended up doing was adding all the @synthesize directives Xcode5 complained about and then committing that locally. Then I ran the wizard and it sailed through. Then I stashed those changes and also backed out the @synthesize commit. Then applied the stashed wizard changeset. A basic smoketest of the app seems to pass, so *shrug*. We'll see what the fallout is down the line.
|
|
#
?
Sep 17, 2013 04:30
|
|
|
Updating my apps for iOS 7 is making me realize how much I've learned since I started making apps (or, alternatively, what an utter moron I used to be). Jesus what the hell was I thinking?
|
|
#
?
Sep 17, 2013 21:50
|
|
|
PT6A posted:Updating my apps for iOS 7 is making me realize how much I've learned since I started making apps (or, alternatively, what an utter moron I used to be). Jesus what the hell was I thinking? I've had so many  moments doing this as well.
|
|
#
?
Sep 17, 2013 23:23
|
|
|
Doh004 posted:I've had so many Well, it turns out I wasn't as stupid as I thought. After spending an hour trying to figure out how to get AutoLayout to do something rather than doing it in code (to account for the stupid 20px status bar thing), I finally gave up and just did it manually. Every time I try to do anything that isn't completely trivial with AutoLayout, it ends up behaving in a completely unintuitive and useless way. Here's a tip, Apple: if I have vertical spacing set on the top and bottom of a view, it might mean I want you to resize that view to maintain the vertical spacing constraints if the superview changes size! EDIT: Of course, if I ever sustain the same sort of brain damage that seems to have occurred to whoever designed AutoLayout and it finally makes sense to me, I'll probably look back at this moment and wonder what I was thinking too. PT6A fucked around with this message at 00:27 on Sep 18, 2013 |
|
#
?
Sep 18, 2013 00:17
|
|
|
|
| # ? May 22, 2024 15:27 |
|
|
I've just started getting into iOS development over the last couple months and Autolayout is by far the biggest wtf I've come across. I *still* don't understand it and trying to get a view to scale how I want comes down to deleting random constraints until both IB is happy and I get the behavior I want. More often than not these are two conflicting requirements.
|
|
#
?
Sep 18, 2013 00:45
|
|
