|
Inevitable Ross posted:Release vs debug mode? Missing copy/include in a build phase? Build phases should be fine :\ It just seems like some file isn't making it over to the build machine. I think this may have to do with the libCrashReporter-iphoneos.a file? Originally, the only one I could get to build from the source was the simulator one. I couldn't even find concrete instructions on how to do this correctly. I'm just confused and frustrated from the day Doh004 fucked around with this message at 00:00 on May 24, 2013 |
# ? May 23, 2013 23:53 |
|
|
# ? May 17, 2024 07:29 |
|
Doh004 posted:Build phases should be fine :\ It just seems like some file isn't making it over to the build machine. That include path is for a Framework, if you are building from source you probably just want <PLCrashreporter.h> Also if I remember correctly it works from the simulator but not from the debugger. For Testing one of the engineers wrote a function that forced a null ptr dereference like: code:
|
# ? May 24, 2013 02:29 |
|
How many source files are we talking about here? If there aren't very many, it might be easier to just copy the source files into your project directly instead of trying to build PLCrashReporter as a separate library linked into your app. edit: also, what privacy concerns? It's not like a crash report has anything personally identifiable in it. HockeyApp always asks the user before submitting a crash report, and Crashlytics can be configured to do so.
|
# ? May 24, 2013 03:29 |
|
When I started my latest project I used CocoaPods from the start and it's completely alleviated all of my library headaches.
|
# ? May 24, 2013 04:16 |
|
Thanks for the responses guys, your help is really appreciated. If I could, I'd send you all cookies.Hughlander posted:That include path is for a Framework, if you are building from source you probably just want <PLCrashreporter.h> Also if I remember correctly it works from the simulator but not from the debugger. For Testing one of the engineers wrote a function that forced a null ptr dereference like: I am unable to import just the .h file. The only thing that autocompletes is the <CrashReporter/CrashReporter.h> file. You are correct that it doesn't work in the simulator. The thing that confuses me is I'm able to do a cmd + r to a physical device (connected via USB) and have it run off there. I've successfully caught uncaught exceptions and have been sending them over to our own error logging on our machines. So I know it's working, I just can't build it outside of my machine. Doc Block posted:How many source files are we talking about here? If there aren't very many, it might be easier to just copy the source files into your project directly instead of trying to build PLCrashReporter as a separate library linked into your app. The instructions that I found on StackOverflow (none are on the actual PLCrashReporter's website, terrible documentation) said that I needed to include both the .a file, which I build from the source, as well as the Crashreporter.framework. Is this not the case? In regards to the privacy concerns, I agree whole heartidly and I fought as much as I, the mobile developer, could to remain with Crashlytics. Long story short, we have some clients whose contracts explicitly states they want NO records of their use of the platform for some ungodly reason. This even means the error logs they have on our website have little to no information for us to debug with should the need arise. I know it's unfortunate, but you have to make do. vapid cutlery posted:When I started my latest project I used CocoaPods from the start and it's completely alleviated all of my library headaches. The next time I start one I will definitely be checking that out. How hard is it to convert over an existing project? I see that I have 8 frameworks currently in my solution. Doh004 fucked around with this message at 14:43 on May 24, 2013 |
# ? May 24, 2013 14:40 |
|
Doh004 posted:The next time I start one I will definitely be checking that out. How hard is it to convert over an existing project? I see that I have 8 frameworks currently in my solution. My main complaint about CocoaPods is that it's still pre-1.0 and acts like it, so if you don't pin to a specific version you'll occasionally have things break from new releases and suddenly you're dicking around with Gemfiles and bundler for your iOS app (which isn't a big deal at all for people who use Ruby anyway, but for those that don't it's yet another thing to learn). I still wouldn't even consider not using it for a new project, though.
|
# ? May 24, 2013 15:18 |
|
Sometimes I wonder if my son (5 months old) will be into software like I was; how exciting to be able to write an app that your friends can run on their phones, or even sell it and make some money. Then I wonder if he'll still be loving about with header files, dumping everything into a single global namespace, and all the rest of the C tool chain bullshit in 10-20 years. Then I get depressed
|
# ? May 24, 2013 15:49 |
|
Ender.uNF posted:Sometimes I wonder if my son (5 months old) will be into software like I was; how exciting to be able to write an app that your friends can run on their phones, or even sell it and make some money. Well, he could always learn to make Android apps. Java deals with a lot of bullshit C problems while introducing a number of its own. I'm surprised no one's jumped on Python as the main development language for mobile apps. Yeah, bytecode can be slow, but on the other hand: Android uses Java.
|
# ? May 24, 2013 16:12 |
|
PT6A posted:I'm surprised no one's jumped on Python as the main development language for mobile apps. Yeah, bytecode can be slow, but on the other hand: Android uses Java. And this, boys and girls, shows just how miserable of a failure Symbian is.
|
# ? May 24, 2013 16:54 |
|
Doctor w-rw-rw- posted:And this, boys and girls, shows just how miserable of a failure Symbian is. I didn't know that still existed.
|
# ? May 24, 2013 16:59 |
|
Anyone has had to deal with undocumented error code -12985? it's thrown by CoreAudio when you attempt to restart an audio unit from background after an interruption... but only some times. Our application is a VoIP dialer, and it puts the call on hold when it receives an audio interruption - like, when you receive a voice call - and then resumes it when the interruption ends. Sometimes our application is put in background during the interruption, sometimes it isn't; sometimes it can restart the audio unit when it's in background, and sometimes it can't; when it can't, it won't stream audio anymore, and the server will automatically close the call for RTP inactivity after 10 seconds. This issue is confirmed by several mailing list posts describing pretty much an identical scenario, but nobody could offer a solution. Any idea?Doctor w-rw-rw- posted:And this, boys and girls, shows just how miserable of a failure Symbian is. Aw, don't hate on poor Symbian, it's a product of another era
|
# ? May 24, 2013 17:17 |
|
Plorkyeran posted:Probably not very difficult if all your deps have podspecs, you have your deps well segregated, and aren't already using a xcworkspace. Yeah when I was evaluating it I realized that it automatically upgrading would probably become a problem so I pinned everything to the version they were at when I started putting things together. The big problem I see now is that it isn't very apparent when libraries have updated if you pin the versions you're using. I haven't checked 0.20 for this feature, though.
|
# ? May 24, 2013 17:30 |
|
vapid cutlery posted:Yeah when I was evaluating it I realized that it automatically upgrading would probably become a problem so I pinned everything to the version they were at when I started putting things together. The big problem I see now is that it isn't very apparent when libraries have updated if you pin the versions you're using. I haven't checked 0.20 for this feature, though.
|
# ? May 24, 2013 18:08 |
|
Plorkyeran posted:The approach I've been taking is to not put version numbers in the Podfile (or major only) and commit Podfile.lock, then whenever I feel like pulling in updated versions of dependencies just delete Podfile.lock, rerun pod install, and commit the result after verifying that everything still works. I actually commit the pods along with the podfile and lock. No reason not to, IMO. Easiest to reproduce the build on machines where CocoaPods is not installed (that's how I was able to migrate a codebase to use it which was previously a huge mess).
|
# ? May 24, 2013 18:22 |
|
hackbunny posted:Anyone has had to deal with undocumented error code -12985? it's thrown by CoreAudio when you attempt to restart an audio unit from background after an interruption... but only some times. Our application is a VoIP dialer, and it puts the call on hold when it receives an audio interruption - like, when you receive a voice call - and then resumes it when the interruption ends. Sometimes our application is put in background during the interruption, sometimes it isn't; sometimes it can restart the audio unit when it's in background, and sometimes it can't; when it can't, it won't stream audio anymore, and the server will automatically close the call for RTP inactivity after 10 seconds. This issue is confirmed by several mailing list posts describing pretty much an identical scenario, but nobody could offer a solution. Any idea? I can't recall that specific error but I have noticed that my audio session gets killed or has its settings reset when resuming from background. Now I always go through and re-initialize all of the settings when resuming and it seems to have solved the problem.
|
# ? May 24, 2013 18:59 |
|
Our TeamCity machine can't even build with CocoaPods and the HockeyApp (PLCrashReporter). We even tried a brand new project with just the pod in it and the same error of not being able to find <CrashReporter/CrashReporter.h>.
|
# ? May 24, 2013 19:05 |
|
I thought I hit on a solution to my Collection View Controller woes by using this subclass override of UICollectionViewFlowLayout, but it dumps my section header out of IB and won't let me throw one in. I guess I have to implement it from scratch, but it seems weird that using a 'custom' layout that is the same as the Flow layout would boot the header from IB.
|
# ? May 24, 2013 20:01 |
|
Doctor w-rw-rw- posted:I actually commit the pods along with the podfile and lock. No reason not to, IMO. Easiest to reproduce the build on machines where CocoaPods is not installed (that's how I was able to migrate a codebase to use it which was previously a huge mess). It can make your repository huge and everything a lot slower (although you can partially mitigate that by adding Pods to .gitignore and force-adding it). I do agree that it's usually the right choice, though.
|
# ? May 24, 2013 20:05 |
|
Doh004 posted:Our TeamCity machine can't even build with CocoaPods and the HockeyApp (PLCrashReporter). We even tried a brand new project with just the pod in it and the same error of not being able to find <CrashReporter/CrashReporter.h>. SON OF A BITCH Turns out TeamCity cannot check out symlinks correctly from Git in server-side mode, only agent checkout mode. It couldn't find the .h files because they weren't being checked out!
|
# ? May 24, 2013 20:29 |
|
AHHHH why didn't I just change the Class of the existing flow layout god drat 4 hours wasted and I think I'm actually dumber now.
|
# ? May 24, 2013 21:10 |
|
Are there any rejection risks doing this?code:
|
# ? May 25, 2013 00:35 |
|
Campbell posted:Are there any rejection risks doing this? I have used undocumented view controller life cycle change notifications in an app that has been through a full submission and multiple updates without a problem. Of course, YMMV and it might break after an OS update.
|
# ? May 25, 2013 02:09 |
|
Sorry to double post but does anyone here have first-hand impressions of ReactiveCocoa? I'm considering using it in a project because it seems like it'd be really nice for the kinds of things I'm going to have to do.
|
# ? May 25, 2013 05:30 |
|
I used it for a toy app recently, and I'd be inclined to use it again on something larger. The documentation isn't great, and creating signals is way more convoluted than it should be (not in that there's dumb boilerplate, but that it's such a core thing to do that making it trivial to create signals should have been a core design goal). I've definitely become a fan of FRP, though. It makes a lot of common things absurdly simpler, and saves you from callback hell when writing async code. The documentation is mitigated somewhat by the fact that the source is pretty reasonable and well organized - it does have good high-level docs, and for a detailed reference it's easy enough to just look at the implementation.
|
# ? May 25, 2013 05:53 |
|
Sadness coming from the collection view front. I've been getting a crash when inserting, deleting, and moving cells. I get an assertion error *** Assertion failure in -[UICollectionViewData indexPathForItemAtGlobalIndex:] where it checks the header's index as if it's a cell. Turns out this is a known bug: http://openradar.appspot.com/12954582quote:The problem turns out to be that when a UICollectionView has decoration views (in your case a section header) this can cause the UICollectionView to crash during updates. One workaround to this problem would be to remove the section header from your UI. Okay, that's kind of rough. Section headers are kind of an important UI element in my view: But I guess it's time to kick them to the curb and drop my own views in there.
|
# ? May 25, 2013 16:08 |
|
And since I can't figure out how to track section size, it looks like I'll have to have multiple single section collection views strung down along a containing scrollview. It seems like a such a weird thing to do.
|
# ? May 25, 2013 16:40 |
|
Did you bail on writing your own layout class? That's sounding more and more like the right choice.
|
# ? May 25, 2013 16:53 |
|
pokeyman posted:Did you bail on writing your own layout class? That's sounding more and more like the right choice. I subclassed the flow layout. The only methods I overrode were layoutAttributesForElementsInRect: and layoutAttributesForItemAtIndexPath:. I couldn't find a layout solution to the assertion failure problem, so I don't know what more to do. But if there was a point where I could jack in to report back section frames (and then manage the layout of my own 'headers'), that would just about do it.
|
# ? May 25, 2013 17:10 |
|
So maybe it's time to subclass the generic layout and reimplement half of the flow layout?
|
# ? May 25, 2013 17:39 |
|
pokeyman posted:So maybe it's time to subclass the generic layout and reimplement half of the flow layout? Probably, but I'm chickening out. You can ask the layout for cell frames, so by checking the last cell frame in each section I can move my 'headers' around. Working pretty well:
|
# ? May 25, 2013 18:04 |
|
Nice! What are you using to make the gifs?
|
# ? May 25, 2013 18:04 |
|
pokeyman posted:Nice! What are you using to make the gifs? QuickTime Player screen recording and Photoshop. edit: be warned, though, the capture frame rate varies a lot, so it's tough to get the speed right. And the gifs are huge.
|
# ? May 25, 2013 18:13 |
|
I've encountered an issue I haven't found much information on. I'm creating an iOS ap for some friends' music festival, and I decided to do a native web app to speed up the development process. I was going try forcing landscape orientation, to see how it'd look, but when I create a 100% width div it's actually only as wide as the height(so, I'm guessing it thinks it's in portrait). Printing out the screen's width to the console verifies this. Is there some strange voodoo I need to counteract? The app is definitely set to use only the landscape orientations.
|
# ? May 26, 2013 18:52 |
|
xpander posted:I've encountered an issue I haven't found much information on. I'm creating an iOS ap for some friends' music festival, and I decided to do a native web app to speed up the development process. I was going try forcing landscape orientation, to see how it'd look, but when I create a 100% width div it's actually only as wide as the height(so, I'm guessing it thinks it's in portrait). Printing out the screen's width to the console verifies this. Is there some strange voodoo I need to counteract? The app is definitely set to use only the landscape orientations. Are you checking against the frame or the bounds of the view? Bounds is what you want to look at to determine the view's dimensions as they are in rotation. Sorry to spam the thread with UICollectionView oddities, but I can't crush this animation oddity. Cells disappear passed the bottom of the view. The first time they reappear they will do so gracefully, with the expected animation coming from off-screen. All subsequent re-entries will produce a second, fixed image of the cell while it also animates into view. Watch for the incoming cells. The first time (good): http://i.imgur.com/3NhepMB.gif All subsequent times (bad): http://i.imgur.com/23QP4T1.gif I've done this even without my subviews, and the same thing happens (the cell appears twice on re-entry, one animated and one not).
|
# ? May 26, 2013 22:43 |
|
lord funk posted:Are you checking against the frame or the bounds of the view? Bounds is what you want to look at to determine the view's dimensions as they are in rotation. Originally I was checking against the frame, but I just tested against the bounds and the width is still reporting as 768. One thing I did notice - my testing device is an iPad 2. I left it upstairs and was too lazy to go get it, so I tried using the sim and noticed that when it launches it is in portrait. Once it finishes loading it switches to landscape. I suspected maybe it somehow launched apps in portait and then checks the app's orientation constraints or something. I don't know if this really proves it though. And more importantly, I still don't know what to do about it.
|
# ? May 26, 2013 23:19 |
|
You can set the allowed orientations right there in Xcode. If you disable the portrait orientations, it will launch in landscape. edit: your app will launch in landscape. the simulator seems to always launch in portrait, but that shouldn't affect anything.
|
# ? May 27, 2013 00:23 |
|
Sorry, I should have clarified that the allowed orientations were set to landscape only. The app never rotates into portrait.
|
# ? May 27, 2013 01:47 |
|
Have any of you guys heard of or used Beeblex to do your IAP receipt validation for you? I'm really not too keen on having to buy and set up my own validation server, and this seems like it would save me a lot of time. Kind of seems to good to be true, though. Especially with them having not updated their SDK since before the iPhone 5 came out. Doc Block fucked around with this message at 04:07 on May 28, 2013 |
# ? May 27, 2013 06:17 |
|
Awesome, our Jenkins iOS builds have all started failing at random places with no useful information at all unless someone runs fuxcode on the Jenkins box for every build.
|
# ? May 28, 2013 06:47 |
|
|
# ? May 17, 2024 07:29 |
|
Update:hackbunny posted:Anyone has had to deal with undocumented error code -12985? it's thrown by CoreAudio when you attempt to restart an audio unit from background after an interruption... but only some times. Our application is a VoIP dialer, and it puts the call on hold when it receives an audio interruption - like, when you receive a voice call - and then resumes it when the interruption ends. Sometimes our application is put in background during the interruption, sometimes it isn't; sometimes it can restart the audio unit when it's in background, and sometimes it can't; when it can't, it won't stream audio anymore, and the server will automatically close the call for RTP inactivity after 10 seconds. This issue is confirmed by several mailing list posts describing pretty much an identical scenario, but nobody could offer a solution. Any idea? I fixed this. To start audio from the background, you have to register to receive remote control events, using something to the effect of [[UIApplication sharedApplication] beginReceivingRemoteControlEvents]. No, you won't actually receive remote control events related to audio, but it's necessary to do audio stuff from the background. So, the lesson is, if you've been getting error -12985, just stick [[UIApplication sharedApplication] beginReceivingRemoteControlEvents] somewhere and call it a day. And [self becomeFirstResponder] on the view controller (don't forget to override canBecomeFirstResponder!). Do it in viewWillAppear or viewDidAppear, whichever actually fires for you, I have no idea. Don't forget to undo it in viewWillDisappear, I guess We've gone full circle from Windows 3.11 and we're back to tying all sorts of unrelated poo poo to the UI state and message loop. iOS, I kind of hate you already, I can tell it's the start of a great friendship
|
# ? May 28, 2013 13:47 |