|
pokeyman posted:If/when the app goes through App Store review, consider leaving a quick note explaining why the assets are in the Documents folder (e.g. so users can customize sounds). I've been rejected before simply because I lacked an explanation. Long distance high five, but it looks like I'll be putting all my preset documents in the user documents folder for easy editing / saving / deleting. Good to know that I should leave a note to the reviewers.
|
#
?
Feb 20, 2014 23:53
|
|
|
|
| # ? May 15, 2024 13:25 |
|
|
lord funk posted:Long distance high five, but it looks like I'll be putting all my preset documents in the user documents folder for easy editing / saving / deleting. Good to know that I should leave a note to the reviewers. What makes it necessary to copy all the files during launch?
|
|
#
?
Feb 21, 2014 06:49
|
|
|
Apple bought Testflight...finally.
|
|
#
?
Feb 21, 2014 20:10
|
|
|
Can apps in the App Store get content updates from the developer's servers? I understand that usually you have to go through Apple for in app purchases and the like, but if I want to offer user-created content to people, such as custom maps for my game, can I do that without going through Apple? I intend to offer everything for free, so Apple cannot object to me cutting out their profits, since there will be no profits anyway.
|
|
#
?
Feb 21, 2014 21:08
|
|
|
Pseudo-God posted:Can apps in the App Store get content updates from the developer's servers? I understand that usually you have to go through Apple for in app purchases and the like, but if I want to offer user-created content to people, such as custom maps for my game, can I do that without going through Apple? I intend to offer everything for free, so Apple cannot object to me cutting out their profits, since there will be no profits anyway. Apple doesn't host anything beyond the base app package. Even if you did want to offer IAP, all Apple will do is confirm that the purchase occurred- if it relies on external files you'd still have to host them yourself.
|
|
#
?
Feb 21, 2014 21:14
|
|
|
haveblue posted:Apple doesn't host anything beyond the base app package. Even if you did want to offer IAP, all Apple will do is confirm that the purchase occurred- if it relies on external files you'd still have to host them yourself.
|
|
#
?
Feb 21, 2014 22:07
|
|
|
Mikey-San posted:What makes it necessary to copy all the files during launch? Just the first time it's launched. How else are they supposed to get there? My app is a synth with patch files the user can edit and save. It comes with a bunch of preset patches, but I'm allowing the user to save and delete them just like the custom patches they make. I figured there were two ways to do this: 1) Store the presets separately, mix together in code 2) Throw them in with the user's patches A lot of time has gone into a system that scans the patches in the Documents folder for tags, so the user can search and organize their patches. What I was facing with (1) was having to keep track of whether or not the presets were replaced by user patches or deleted, when saving, renaming, ahhhhh. In the end, it's easier to treat them the way I designed them: just like user patches. Heck, if you want to clear out all the presets I made and just go hog wild with your own, you could just delete them all in iTunes File Sharing.
|
|
#
?
Feb 21, 2014 22:28
|
|
|
ultramiraculous posted:Apple bought Testflight...finally. And not surprisingly, support for Android ends on March 21st. Not great for a cross-platform development team that just started to get comfortable with TestFlight...
|
|
#
?
Feb 22, 2014 04:51
|
|
|
Good-Natured Filth posted:And not surprisingly, support for Android ends on March 21st. Not great for a cross-platform development team that just started to get comfortable with TestFlight... We've been using TestFlight for our iOS app for the past year. We just got support to start our Android app and I pushed hard to get them to use TestFlight. Whoops 
|
|
#
?
Feb 22, 2014 06:29
|
|
|
Is NSHTTPCookieStorage not sandbox local? Goddamn it Apple, there's exactly what I need but it only exists on Snow Leopard for some unknowable reason.
|
|
#
?
Feb 22, 2014 07:35
|
|
|
Considering TestFlight 86'd their iOS SDK too, it looks like this is a case of them starting to wind down the service altogether, not just jettisoning Android. They're obviously just cutting Android off first because Apple. That's a shame, because I really loved the SDK's crash reporting feature that linked stackdumps with the actual tester/device and automatically symbolicated them.
|
|
#
?
Feb 22, 2014 16:23
|
|
|
kitten smoothie posted:Considering TestFlight 86'd their iOS SDK too, it looks like this is a case of them starting to wind down the service altogether, not just jettisoning Android. They're obviously just cutting Android off first because Apple. On the other hand, it may signal Apple will finally implement a beta program in the coming months. I expect this to be announced at WWDC if so. Other services will probably pop up to fill TestFlight's role for whatever Apple shuts down.
|
|
#
?
Feb 22, 2014 18:21
|
|
|
So the internets found out why that security update for iOS 7 came out. Comes with free gloating about bracing your if statements. tl:dr apple engineer didn't brace an if statement and fails through a bunch of SSL checks in the algorithm. Also subtle bugs suck balls. ptier fucked around with this message at 19:53 on Feb 22, 2014 |
|
#
?
Feb 22, 2014 19:49
|
|
|
Don't use goto statements either, if you can avoid it at all. I'd have just done a big "if...else if...else" thing with the failure code in an else block at the end, which would've had the added bonus that the compiler would've caught the bug, since there would've been (from the compiler's perspective) a wild "else if" statement.
|
|
#
?
Feb 22, 2014 20:43
|
|
|
GOTOs are a perfectly valid C-level error handling mechanism when used to jump short distances to failure handling code or unwind errors. Jumping within a very small block is well-defined behavior and in line with the assembly that a less transparent if-else chain might generate (not that having an if-else chain is not a valid solution). The problem here was the lack of braces causing a logic error, not the GOTOs.
|
|
#
?
Feb 22, 2014 21:15
|
|
|
I know it wasn't the GOTOs causing the problem. I was just pointing out that using a string of if-else statements would've made the code fail to compile instead of have a subtle bug.
|
|
#
?
Feb 22, 2014 21:37
|
|
|
Doc Block posted:Don't use goto statements either, if you can avoid it at all. I'd have just done a big "if...else if...else" thing with the failure code in an else block at the end, which would've had the added bonus that the compiler would've caught the bug, since there would've been (from the compiler's perspective) a wild "else if" statement. Compiler did catch the bug. Warning: Unreachable code. Which would be a process failure that the warning was ignored in shipped code.
|
|
#
?
Feb 22, 2014 21:44
|
|
|
Either that warning is off by default in Xcode or one of my coworkers did an odd thing. Ask me how I know!
|
|
#
?
Feb 22, 2014 21:56
|
|
|
Doctor w-rw-rw- posted:On the other hand, it may signal Apple will finally implement a beta program in the coming months. I expect this to be announced at WWDC if so. Other services will probably pop up to fill TestFlight's role for whatever Apple shuts down. We're switching to HockeyApp for Android and maybe iOS too, we're grandfathered into TestFlight as it were so maybe we can stick it out until Apple gets their own thing out there. If Apple were to chew up TestFlight and spit out some other product, I wish they'd basically just take TestFlight but let you enroll named beta users using Apple IDs instead of device UUIDs, distribute betas to named users via the App Store, and keep everything else the same.
|
|
#
?
Feb 22, 2014 22:31
|
|
|
Hughlander posted:Compiler did catch the bug. Warning: Unreachable code. In the article it was -Wunreachable-code did but it won't if -Wall is just used. Why that isn't part of Apple's process / why doesn't -Wall do -Wunreachable-code is another question.
|
|
#
?
Feb 22, 2014 23:48
|
|
|
gcc can't add things to -Wall because that breaks all the terrible projects that have -Werror in their default CFLAGS and the users throw a shitstorm. Clang might be able to get away with it due to that there's a lot less legacy code being compiled with it.
|
|
#
?
Feb 23, 2014 00:01
|
|
|
Plorkyeran posted:gcc can't add things to -Wall because that breaks all the terrible projects that have -Werror in their default CFLAGS and the users throw a shitstorm. Clang might be able to get away with it due to that there's a lot less legacy code being compiled with it. Why is having -Werror in your CFLAGS bad? If you are releasing code that triggers warnings when it is compiled, you should be drawn and quartered/thrown off a cliff/add -Wno-specific-warning to the specific file with the issue if it is unfixable.
|
|
#
?
Feb 23, 2014 00:24
|
|
|
Plorkyeran posted:gcc can't add things to -Wall because that breaks all the terrible projects that have -Werror in their default CFLAGS and the users throw a shitstorm. Clang might be able to get away with it due to that there's a lot less legacy code being compiled with it. Ahh ok, that makes complete sense. Still shouldn't stop Apple from testing against unreachable code. But a technical reason why not just dumping it into -Wall and calling it a day.
|
|
#
?
Feb 23, 2014 00:24
|
|
|
Sinestro posted:Why is having -Werror in your CFLAGS bad? If you are releasing code that triggers warnings when it is compiled, you should be drawn and quartered/thrown off a cliff/add -Wno-specific-warning to the specific file with the issue if it is unfixable. Your compiler may not produce warnings in the exact same situations as the compiler used by someone who just wants to use your software. Enabling -Werror by default is going out of your way to make your software less portable.
|
|
#
?
Feb 23, 2014 00:32
|
|
|
Plorkyeran posted:gcc can't add things to -Wall because that breaks all the terrible projects that have -Werror in their default CFLAGS and the users throw a shitstorm. Clang might be able to get away with it due to that there's a lot less legacy code being compiled with it. The -Weverything is hip and relevant LLVM compiler flag to get all the warnings turned on.
|
|
#
?
Feb 23, 2014 02:11
|
|
|
The design for these things is that you occasionally do test runs with -Weverything or whatever and then selectively add stuff that you think is useful to your actual builds. Setting -Weverything in a build that somebody else might reasonably do with a random compiler release is still rude. We also regularly enable new warnings in the Xcode project templates but not in existing projects when we think something is best practice but maybe not worth foisting on everyone. Relatedly, it's a good idea to audit the set of newly available warnings whenever your project officially moves to a new Xcode.
|
|
#
?
Feb 23, 2014 08:36
|
|
|
Not sure if this would help anybody but I discovered an OpenGL ES mipmap generation bug for A7 devices (5S, etc). Apparently using the standard OpenGL calls to generate mipmaps with non-square textures is causing problems. I was wondering why my particle engine was spitting out particles that looked much different between my 5S and my 4... it was only in GLES 2.0 that this was a problem - 1.1 was fine. At first I thought it was shader precision (because there's a change in "lowp" for A7) and I was hashing the data going into glTexImage2D between the devices just to make sure the data was the same. There were fleeting moments that the particles looked correct so I turned off mipmapping and everything went back to normal. I googled for this and the only thing I found was a thread on TouchArcade that said someone had to fix a bug in their game because A7 mipmapping generation for non-square textures wasn't working:quote:Issue resolved. Obscure change in A7 64bit OpenGL ES implementation meant that any non-square texture could not get mipmaps generated with the normal OpenGL ES calls. Performing my own reduction solved the issue. Apple's documentation had nothing about this issue.
|
|
#
?
Feb 24, 2014 04:55
|
|
|
Can someone familiar with XNU/Darwin confirm that the 32 bit kernel does not map kernel address space into user processes, so every ring 0 call requires flushing TLBs? And thus a 32 bit process has the entire address space available, as opposed to 2/3GB? I always wondered how the hell the 32 bit kernel could host 64 bit user processes and that finally made it click for me. Since everything has to be remapped anyway, I guess it was no big deal to just remap all the pointers. I know 64 bit Darwin does the standard thing Windows and Linux do: the kernel is mapped into the same region of every process' address space, so calling a kernel function doesn't require swapping page tables and data passed back and forth doesn't need to be mapped into separate address spaces (yes, yes I know).
|
|
#
?
Feb 25, 2014 05:39
|
|
|
Ender.uNF posted:Can someone familiar with XNU/Darwin confirm that the 32 bit kernel does not map kernel address space into user processes, so every ring 0 call requires flushing TLBs? And thus a 32 bit process has the entire address space available, as opposed to 2/3GB? Someone I know might know. I'll ask and post if I get a useful response. I don't know what it means to make a ring 0 call, but if it's system call you're talking about, they're done through libsystem, which determines whether to make a BSD or a Mach syscall, and the behavior is different between 32 and 64-bit. I forget exactly how, but it should be in one of the earlier chapters of the Mac OS X and iOS Internals book. Apple employee posted:At least on iOS, the kernel gets a fixed 1GB mapping, leaving 3GB for user processes (though I believe it's limited to 2GB in practice for reasons I don't remember). Some other guy posted:iOS devices have a static kernel mapping, mapping RAM at VirtBase for 1GB. There can be no more than 1GB of RAM max on iOS device due to limitations in arm_vm_init. Higher memory above is kernel managed. The only /reason/ as for the static kernel mapping is for things such as internal pmap operations, for example, converting between physical -> virtual addresses for allocated TTEs. Linux does something like this too, to a certain extent. There you go. Doctor w-rw-rw- fucked around with this message at 17:30 on Feb 25, 2014 |
|
#
?
Feb 25, 2014 08:53
|
|
|
I'm having a bit of trouble trying to use unwind segues. Here's what I've got VC1 -> VC2 -> VC3 On VC3 there is a button that when pressed, should return to the view controller that called it. However, VC1 or VC2 could have called an instance of VC3. The button only allows me to pick one exit method to unwind to. My code calls the code:
|
|
#
?
Feb 26, 2014 05:56
|
|
|
Doctor w-rw-rw- posted:Someone I know might know. I'll ask and post if I get a useful response. quote:At least on iOS, the kernel gets a fixed 1GB mapping, leaving 3GB for user processes (though I believe it's limited to 2GB in practice for reasons I don't remember). Presumably because device IO is memory mapped so you lose some of the address space? It sounds like iOS at least uses the traditional scheme. This all started when I wanted to figure out how the hell a 32 bit kernel could possibly support 64 bit user mode software since calls into 32 bit kernel land can't read any data via 64 bit pointers, since the transition kicks back down to 32 bit mode. The solution would be to map that 64 bit virtual address into the kernel's 32 bit address space so you have both a 32 and 64 bit pointer to the same physical memory. How that would work practically is unknown though. In the process of reading about that, I saw multiple references to a Mac 32 bit process being able to allocate 4GB of memory and thought that couldn't possibly be correct because the address space is split between a permanent kernel mapping and the user mapping that gets swapped to the currently executing process. But it would appear that is not the case, and a 32 bit Mac app does have free reign over the whole address space. The penalty is that any transition to kernel mode has to ... You guessed it, map the same physical page to a new address space... Which happens to conveniently dovetail with the requirements for running 64 bit processes on a 32 bit kernel, something no other major OS ever attempted. I could be completely wrong about all of this but I try to understand the kernel, MMU, etc at least to some basic level. I think it makes you a better developer, even if you treat it as a black box most of the time.
|
|
#
?
Feb 26, 2014 06:14
|
|
|
Ender.uNF posted:This all started when I wanted to figure out how the hell a 32 bit kernel could possibly support 64 bit user mode software since calls into 32 bit kernel land can't read any data via 64 bit pointers, since the transition kicks back down to 32 bit mode. The solution would be to map that 64 bit virtual address into the kernel's 32 bit address space so you have both a 32 and 64 bit pointer to the same physical memory. How that would work practically is unknown though. It's not impossible, just very tricky. IIRC what happens is that all traps to the kernel save the register state, switch to the kernel's separate address space and into 32-bit mode, and then continue on with kernel operations. All kernel-to-user memory access is mediated through the 'copyin' and 'copyout' kernel functions (man 9 copyin), which can remap the relevant user memory into a temporary mapping in the kernel so it can be copied into a kernel buffer. The 32-bit kernel still has to understand 64-bit userspace pointers, but it never actually dereferences them. It's not essential to have the kernel reserve some part of the user address space, it's just more efficient to do it that way so you don't have to do the remapping dance. 
|
|
#
?
Feb 26, 2014 07:20
|
|
|
Ender.uNF posted:But it would appear that is not the case, and a 32 bit Mac app does have free reign over the whole address space. Ender.uNF posted:I could be completely wrong about all of this but I try to understand the kernel, MMU, etc at least to some basic level. I think it makes you a better developer, even if you treat it as a black box most of the time. I think Chapter 8 might have some related info. If you want to understand OS X the book's probably a good place to start (still working through it myself).
|
|
#
?
Feb 26, 2014 07:22
|
|
|
The correct usage is 'free rain,' as in, rain you do not pay for. 'He had free rain to water his garden.' See?
|
|
#
?
Feb 27, 2014 20:03
|
|
|
In other news I managed to submit a correctly provisioned archive in under ten builds today. A small victory.
|
|
#
?
Feb 27, 2014 20:04
|
|
|
PSA: -[UIViewControllerAnimatedTransitioning animateTransition:] is a terrible time to ask a view controller for its -bottomLayoutGuide, at least when presenting modally. If that view controller hosts a scroll view, its contentSize is immediately set to {0, 0}. Hooray!
|
|
#
?
Feb 27, 2014 21:15
|
|
|
Yo, I'm writing a thing that loads a couple webpages, then when it hits a specific page, throws up a barcode scanner thing, gets a string, then returns to the WebView, inserts it using JS into the page, and lets the user interact with the webpage (basically setting up a web app with a barcode scan in there too). I'm having issues doing the JS stuff, however. Whenever I'm calling it, I'm getting a "WTFCrash" error, due to trying to modify the webpage (the JS poo poo) while it's not in the foreground. pre:"2014-02-28 11:34:23.795 myApp[1665:1803] bool _WebTryThreadLock(bool), 0x155c6e00: Tried to obtain the web lock from a thread other than the main thread or the web thread. This may be a result of calling to UIKit from a secondary thread. Crashing now... 1 0x377145d3 WebThreadLock Currently, the BarcodeScannerViewController segues back to the (subclassed) WebViewController, and in the WebViewController's viewWillAppear method (or viewDidAppear - the behaviour is the same), I call the code to gently caress with the webpage using JS. However, it's not in the foreground, so I still get the WTFCrash. Is there somewhere else in the view heirachy code that's better to call it from that will get called once my WebView returns to being in the foreground? Or should I do some async method fuckery (hacky async sleep then modify original webviewcontroller lol)? Or not use JS to fill my form and do it a different way?
|
|
#
?
Feb 28, 2014 12:38
|
|
|
-viewWillAppear: and -viewDidAppear: should be called on the main thread. Seeing some code would be helpful here, if you can share. Or the backtrace. You can check if you're on the main thread with +[NSThread isMainThread]. Maybe assert that in a couple places and see if it's what you expect.
|
|
#
?
Feb 28, 2014 16:17
|
|
|
Mr SuperAwesome posted:Or should I do some async method fuckery (hacky async sleep then modify original webviewcontroller lol)? Can't you dispatch the part that submits JS to the webview onto the main thread?
|
|
#
?
Feb 28, 2014 16:25
|
|
|
|
| # ? May 15, 2024 13:25 |
|
|
I am so sick of reusable views it's beyond description.
|
|
#
?
Feb 28, 2014 23:24
|
|