|
Not an answer but It's actually a vibrancy blur of the background image. Anyone have experience with CollectionView custom layouts recycling of cells that have an affine transform that affects item size? I am having a bear of a time basically reimplementing flow layout that takes arbitrarily transformed cells. I have a subclassed flow layout that has it's item size set to the desired final width and height, then transformed down to half scale and then manually repositioned to flow. Now I haven't found documentation to point out what all the layout metrics I need to take into account in the layoutAttributesForItemsInRect call to accurately return the right cells over the course span of the contentSize. Or alternately tell me there is a better way to animate scale/zoom changes in a collection view (or ites cells) that isn't resizing itemsize or collection layout attribute's frame property. Changing Item size or frame doesn't give us the scaling affect we want. It also also causes redraw events on all cell subviews which drops frames during animations. The cells contain long scrollviews of text and setting frame in order to animate zooming causes alot of text flow calculations (asynckit won't work because we do lots of embeded content attachments which can't be flowed off the main thread).
|
# ? Nov 26, 2014 04:49 |
|
|
# ? Jun 8, 2024 13:12 |
|
kitten smoothie posted:So in Springboard, if you trigger Reachability mode on a 6/6+, the background remains the same while just the icon content slides down. In other apps though there's a black screen. Are you sure that's not a setting you have on somewhere that might turn that off? I don't know that I've ever seen an app pull down and just show black? For example, my blue-ish background is blurred like so:
|
# ? Nov 26, 2014 05:11 |
|
Accessibility reduce transparency might affect it (or some similar setting)
|
# ? Nov 26, 2014 05:25 |
|
Huh, what do you know, I just have a darker wallpaper so it looked black on my screen. I switched my wallpaper to a lime green and it was more clear that it's not just a black box. Still though, I assume that this effect in Springboard is not something you can accomplish through any public APIs? It's not as jarring as having the whole app screen and status bar just totally move halfway out of view.
|
# ? Nov 26, 2014 05:53 |
|
kitten smoothie posted:Still though, I assume that this effect in Springboard is not something you can accomplish through any public APIs? It's not as jarring as having the whole app screen and status bar just totally move halfway out of view. UIBlurEffect and UIToolbar hacks are the only way to do live GPU-aided blurs. They kinda suck.
|
# ? Nov 26, 2014 06:36 |
|
From what I've seen, any and all API calls regarding Reachability are private/undocumented, so apps don't have any control. e: and it's too bad blur layers are so hard to do on iOS, especially considering in Yosemite all you have to do is slap a visual effects view wherever you want it. carry on then fucked around with this message at 06:39 on Nov 26, 2014 |
# ? Nov 26, 2014 06:37 |
|
carry on then posted:e: and it's too bad blur layers are so hard to do on iOS, especially considering in Yosemite all you have to do is slap a visual effects view wherever you want it. I haven't used it yet so maybe it doesn't work the same as NSVisualEffectView or something, but what's wrong with UIVisualEffectView?
|
# ? Nov 26, 2014 06:47 |
|
carry on then posted:e: and it's too bad blur layers are so hard to do on iOS, especially considering in Yosemite all you have to do is slap a visual effects view wherever you want it. That's exactly what you do on iOS8, but the blur effect configuration is kind of poo poo.
|
# ? Nov 26, 2014 06:57 |
|
Oh wow, I didn't even realize. Must have been added for iOS 8, or did I somehow miss it in iOS 7?
|
# ? Nov 26, 2014 07:02 |
|
They made it available in iOS8. They seem to like introducing cool poo poo (live blur, TouchID in iOS7. NFC in iOS8...will probably be accessible by devs in iOS9) and making it private until the next release.
|
# ? Nov 26, 2014 07:05 |
|
carry on then posted:Oh wow, I didn't even realize. Must have been added for iOS 8, or did I somehow miss it in iOS 7? It's new in 8.0
|
# ? Nov 26, 2014 07:06 |
|
I am feeling really, really dumb today. Why is this bar with 'Done' showing up on my keyboard (in the simulator) and how do I remove it?
|
# ? Nov 26, 2014 19:14 |
|
No idea but that's usually accomplished by setting a UITextView's inputAccessoryView property, maybe you could grep for that.
|
# ? Nov 26, 2014 20:11 |
|
Ahaha of course "Xcode 6.1.1 GM seed" is unsuitable for building binaries for App Store submission. How silly of me to think a GM seed would work for that.
|
# ? Nov 26, 2014 22:07 |
|
I have been tasked with writing a relatively simple iOS app. I have a strong background in OOP with a variety of languages, just want to know if I should start with objective-c or give swift a try.
|
# ? Nov 27, 2014 01:13 |
|
Objective-C is the proven approach. Most examples you find online for "how do I do ___ in iOS" will be in Objective-C. Recent stuff will often have an example snippet in Objective-C and another in Swift. Swift however is very pleasant in general to work with and has a lot of nicer modern amenities if you can deal with the rough edges (which have receded with time). Swift is going to be more performant for end users in the long term.
|
# ? Nov 27, 2014 01:39 |
|
Begby posted:I have been tasked with writing a relatively simple iOS app. I have a strong background in OOP with a variety of languages, just want to know if I should start with objective-c or give swift a try. Given that it sounds like you're doing this for someone else, Objective-C. It's much more well known and widely used. There will definitely be a day when new projects should be initiated in Swift but it's not really ready yet.
|
# ? Nov 27, 2014 01:41 |
|
pokeyman posted:No idea but that's usually accomplished by setting a UITextView's inputAccessoryView property, maybe you could grep for that. this did it. Apparently the third party keyboard manager the guy who wrote this used ,was causing that. Dirk Pitt fucked around with this message at 01:45 on Nov 27, 2014 |
# ? Nov 27, 2014 01:43 |
|
I have to admit that when I write Objective-C now I find it so clumsy by comparison. I would be cautious about using Swift for a client at this point, though.
|
# ? Nov 27, 2014 01:49 |
|
When I write Obj-C code for work, I often find myself commenting on how much better Swift is at parts of it. Despite its at times very rough edges, Swift is a fantastic language and will be really awesome. This next WWDC should bring a lot of good polish to it, assuming we don't get some more stuff before then because WatchKit. That said, I and several of my coworkers look on the Swift vs. Obj-C choice as also being based on timeframes and schedules. If you're looking to knock out an app in a handful of months and be done, Obj-C is probably the way to go. On the other hand, if you're looking at a timeframe of a year or more that the project will be supported, Swift becomes more appealing as a choice: the rough edges you encounter at the start would balance out over the long run, and you'd benefit going forward as the Apple developer community pivots towards it. Shouldn't be your only factor, but something to consider, at least.
|
# ? Nov 27, 2014 02:06 |
|
Ok, guys thanks for the advice. Objective-C it is! The project will be something I will maintain long term as it is for a company I am employed at. However, it does need to be at least workable relatively soon, and I think getting some experience in obj-c will be useful, I can always migrate it to swift later on if I really want to. At least its pretty stupid simple, I could probably crank it out over morning coffee as a windows app. Begby fucked around with this message at 03:44 on Nov 27, 2014 |
# ? Nov 27, 2014 03:29 |
|
Carthage just got a lot more useful, now that it's building only framework targets. If anyone was interested before but got stuck, or was only a little interested, it might be worth another look.
|
# ? Dec 2, 2014 05:30 |
|
Hey, I got tired of writing both UIAlertView and UIAlertController code to support iOS 7 and 8, so I wrote a wrapper to help me out and threw it up on GitHub. Comments and critiques are very welcome, I'm new to GitHub: https://github.com/BayPhillips/compatible-alert-controller
|
# ? Dec 2, 2014 17:30 |
|
Anyone have pointers to some docs on debugging semaphore or GCD deadlocks? Getting a strange situation where NSURLSession creation appears to deadlock on dispatch_semaphore_wait_slow (IIRC) and I'm not familiar with the tools for figuring out who owns a mutex on iOS/OS X. edit: It's NSURLSession sessionWithConfiguration:delegate:delegateQueue: and it hangs on _dispatch_semaphore_wait_slow calling semaphore_wait_trap. On Windows I know how to determine which other thread is holding the mutex but I've never tried that on OS X. edit2: It was fuxcode. It's always fuxcode. Deleting derived data completely fixed the problem. Simulated fucked around with this message at 21:31 on Dec 2, 2014 |
# ? Dec 2, 2014 20:36 |
|
Ender.uNF posted:Anyone have pointers to some docs on debugging semaphore or GCD deadlocks? Semaphores don't have owners like mutexes do - there might be some code that will signal the semaphore in the future, but the semaphore doesn't really know about it. A mutex does know what thread owns it - you can't unlock a mutex from a different thread than the one that locked it, unlike a semaphore. One of the fields in the pthread mutex structure is a thread ID - which is the same hex number identifier that shows up in LLDB/Xcode/spindump/sample/etc.
|
# ? Dec 3, 2014 02:41 |
|
Does Apple hold rejections for obvious reasons against you? I just submitted an app for a client that I knew would get rejected for lack of content, and I told them would get rejected, and they insisted that I do it anyway (I mentioned this in the notes to the reviewer). Am I going to be subjected to greater scrutiny in the future for doing something that was, admittedly, a waste of time for everyone involved, or does it only matter for that single submission?
|
# ? Dec 3, 2014 05:04 |
|
Xcode 6.1.1 just went out on the App Store. It says it fixes common SourceKit crashes with Swift.
|
# ? Dec 3, 2014 05:24 |
|
It also says I'm not part of a development team
|
# ? Dec 3, 2014 06:00 |
|
PT6A posted:Does Apple hold rejections for obvious reasons against you? I just submitted an app for a client that I knew would get rejected for lack of content, and I told them would get rejected, and they insisted that I do it anyway (I mentioned this in the notes to the reviewer). Am I going to be subjected to greater scrutiny in the future for doing something that was, admittedly, a waste of time for everyone involved, or does it only matter for that single submission? I doubt anybody here is in a position to simultaneously know the answer and be willing to tell you. But I'm guessing the answer is no, unless this you're doing something silly like submitting ten thousand app updates that are all obviously content-free. Not sure why you left a note for the reviewer though. Let them figure out you're wasting their time!
|
# ? Dec 3, 2014 06:02 |
|
I'd guess that you'd maybe face stricter scrutiny on subsequent builds of that same app and no difference to other apps. I would have spared the notes to the reviewer expecting to be rejected.
|
# ? Dec 3, 2014 07:34 |
|
PT6A posted:Does Apple hold rejections for obvious reasons against you? I just submitted an app for a client that I knew would get rejected for lack of content, and I told them would get rejected, and they insisted that I do it anyway (I mentioned this in the notes to the reviewer). Am I going to be subjected to greater scrutiny in the future for doing something that was, admittedly, a waste of time for everyone involved, or does it only matter for that single submission? This would require them to have their poo poo together and not accidentally reject you multiple times for the same reason even though they've written notes to themselves that the issue was resolved. So, I'm going to go out on a limb here and say no - not unless you're a pathological case of submitting tons of shitware / continuously submit awful apps.
|
# ? Dec 3, 2014 08:11 |
|
Doctor w-rw-rw- posted:continuously submit awful apps.
|
# ? Dec 3, 2014 11:10 |
|
pokeyman posted:Not sure why you left a note for the reviewer though. Let them figure out you're wasting their time! ManicJason posted:I'd guess that you'd maybe face stricter scrutiny on subsequent builds of that same app and no difference to other apps. I would have spared the notes to the reviewer expecting to be rejected. Just to clarify that point, I didn't say I expected that, I said I was familiar with that section of the submission guidelines and that I had explained them to my client, who responded that they wanted it in an app rather than a website because the areas where it would be used were often in cellular range, but didn't always have data coverage. It was really, really featureless (literally a logo, a phone number, and a button to dial the phone number), though, so I'm guessing it doesn't really matter what I said or didn't say in the notes. It literally took me 10 times longer to arrange all the image assets than it did to code the app.
|
# ? Dec 3, 2014 21:24 |
|
I was responding to the parenthetical in this quote:PT6A posted:I just submitted an app for a client that I knew would get rejected for lack of content, and I told them would get rejected, and they insisted that I do it anyway (I mentioned this in the notes to the reviewer). My apologies if I misunderstood the remarks you left for the reviewer.
|
# ? Dec 3, 2014 22:29 |
|
pokeyman posted:I was responding to the parenthetical in this quote: Yeah, I didn't phrase that very well, but, regardless, I submitted an app I knew would be rejected, regardless of any other factors. I've submitted the client a list of functionality we could add to qualify it, but I haven't heard back yet. I still haven't figured out why in god's name they think they need an app in the first place, of course.
|
# ? Dec 3, 2014 22:52 |
|
I have the strangest behavior with my table view. I have an accessory on the right side of my cells that pushes a view controller containing a web view. If I repeatedly hit that button and unwind back to the table view, the state of the table view *always* gets screwed up. Sometimes it will refuse to highlight the selected cell, but will still handle the events. Sometimes it will handle events in some cells but not others. Sometimes there will be weird gaps between cells or duplicate cells. Going to another tab and back with the tab bar always fixes it. I have tried various combinations of reloadSections, reloadData, setNeedsDisplay, blah blah blah, and I'm not coming up with anything. Anyone have a clue? edit: In addition, continuing to go to the web view and back when it misbehaves can fix the behavior. brap fucked around with this message at 08:22 on Dec 4, 2014 |
# ? Dec 4, 2014 07:52 |
|
fleshweasel posted:Going to another tab and back with the tab bar always fixes it. How are you sizing cells? If your answer includes "constraints" at any point, I would instantly suspect it. Autolayout on iOS is a god drat nightmare.
|
# ? Dec 4, 2014 08:18 |
|
I can't reproduce the issue when using a modal segue, but I can pretty consistently produce it when using a push segue. Does that imply any potential cause? edit: In fact, if I implement my own button to trigger the unwind instead of using the back button that gets generated, I can't make it screw up either. However, then I lose the left edge swipe to go back. I would be fine having my own "done" button for this but I really want that gesture. I will just have to experiment with that bit. It seems like an unwind segue I had left around in my storyboard might have been loving it up intermittently. I've removed them and gone back to the show segue, and it seems to be working properly. brap fucked around with this message at 09:57 on Dec 4, 2014 |
# ? Dec 4, 2014 09:13 |
|
fleshweasel posted:I can't reproduce the issue when using a modal segue, but I can pretty consistently produce it when using a push segue. Does that imply any potential cause? If you get forced into reimplementing it you could use UIScreenEdgePanGestureRecognizer to do the gesture as well.
|
# ? Dec 4, 2014 12:59 |
|
|
# ? Jun 8, 2024 13:12 |
|
Anyone who's done app preview videos: you get to choose one interface orientation, right? Either portrait or landscape, but not both?
|
# ? Dec 4, 2014 16:20 |