|
pokeyman posted:There are a few names on some blacklist that can trigger this. I think naming a property `id` is one of them. setEffects: was the property.
|
# ? Oct 14, 2013 22:59 |
|
|
# ? May 15, 2024 03:27 |
|
Glimm posted:I don't think so, but just a style note - I'd write that as: Also, BOOL is just a typedef to char, and YES and NO are just preprocessor defines (to 1 and 0, respectively), so it's generally a good idea to check for NOT NO instead of checking for YES in case some buffoon decides to do something clever and just return the contents of an int to indicate success/failure instead of explicitly returning YES or NO. Objective-C code:
Doc Block fucked around with this message at 23:52 on Oct 14, 2013 |
# ? Oct 14, 2013 23:43 |
|
arm64 finally switches to typedef bool BOOL, which fixes that particular issue. You can enjoy saner semantics on all platforms by just using bool rather than BOOL.
|
# ? Oct 15, 2013 00:25 |
|
I don't need me none o' them C++ keywords, y'hear?
|
# ? Oct 15, 2013 00:38 |
|
Doc Block posted:I don't need me none o' them C++ keywords, y'hear? typedef _Bool BOOL then
|
# ? Oct 15, 2013 00:48 |
|
Not sure if this has been mentioned yet but it looks really amazing. I didn't even expect such a thing to be possible: http://revealapp.com
|
# ? Oct 15, 2013 05:04 |
|
NoDamage posted:Not sure if this has been mentioned yet but it looks really amazing. I didn't even expect such a thing to be possible: yeah this loving owns. you can play with your UI while its running live on your phone too, which also owns ~rapid prototyping~ its also good for coord debugging (i have a weird bug atm where a UICollectionView in a nav controller is offset by 64px if you swipe back 3 or more items in the nav heirarchy. swipe back 2 and the offsets are fine?????)
|
# ? Oct 15, 2013 12:51 |
|
Mr SuperAwesome posted:yeah this loving owns. you can play with your UI while its running live on your phone too, which also owns This looks awesome but why can't I find the actual framework to link into the app? I feel so dumb right now *Edit* Yep I'm an idiot, I actually read the instructions and it says where to get it. It's in the help menu of the app. Doh004 fucked around with this message at 16:53 on Oct 15, 2013 |
# ? Oct 15, 2013 16:25 |
|
I'm building a quick prototype with an iPhone app. I have a simple computer on the network. There's a slider in the app that sends its value over http to the simple computer. The naive solution of firing off a synchronous NSUrlRequest in the slider's update method quickly swamped the simple computer, the App didn't get data back on one of the hundreds of requests, dogs and cats living together, etc. How can I rate limit sending the NSUrlRequests? I'm very new to iOS dev, please forgive the basic question. My first idea is to set up a timer, poll the slider's value at a slow (~5Hz?) rate, and only send a request out when a change is detected there.
|
# ? Oct 15, 2013 17:15 |
|
That would work. You could also cache the last time a request was sent and only send if enough time has elapsed.
|
# ? Oct 15, 2013 17:27 |
|
Why not just wait until until the slider stops moving to send the request? Is that an option?
|
# ? Oct 15, 2013 18:49 |
|
The timer solution ended up being very, very easy to do. It's a little jerky in practice, but at this point the demo's so cooked that one more constraint on the user (slide slow) isn't too bad. I didn't dig too far into the slider controls. I assume there's some onUp event I could tie it to? Either way, there has to be some way to rate limit in case a user does a lot of short movements. I'm ok with the timer solution. I literally figured out Reference Outlets in the past 30 minutes, I can't overemphasize how new to iOS I am. The project manager requested hooks to react to SMS, but I'm gathering that couldn't be done. Did iOS7 change any of that or is it still walled off from the app?
|
# ? Oct 15, 2013 19:02 |
|
JawnV6 posted:The timer solution ended up being very, very easy to do. It's a little jerky in practice, but at this point the demo's so cooked that one more constraint on the user (slide slow) isn't too bad. At the risk of stating the obvious: it's jerky because you're running synchronous URL connections on the main thread. The main thread is where the UI runs, so the UI can't process events until your URL connection is finished. This is easily fixable if you feel the urge, and would teach you about delegates which are very important to iOS applications. quote:I didn't dig too far into the slider controls. I assume there's some onUp event I could tie it to? Either way, there has to be some way to rate limit in case a user does a lot of short movements. I'm ok with the timer solution. Check the UIKit User Interface Catalog entry on Sliders. Note the "continuous" option and that the slider sends the "value changed" event. quote:The project manager requested hooks to react to SMS, but I'm gathering that couldn't be done. Did iOS7 change any of that or is it still walled off from the app? As far as I know there's no way for your app to be alerted to the presence of a new SMS message or to read the contents of an SMS message. You could do something like put a custom URL in the SMS which opens your app when tapped.
|
# ? Oct 15, 2013 19:50 |
|
I looked into asynchronous URL's, but I'd kinda rather hang the app rather than flood the device. It's a lot easier to reboot an iOS app than dig into this stupid thing and get to the reset button. I'm not even doing anything with the response, it's just a testing web page from before I had the app. We're actually going to run a wireframe through Airplay and fake the app side too, so I'm generally off the hook for it doing anything besides function. I did a minor rewrite that slowed the timer down to 1Hz and removed the slider update code. The value's pulled in the timer and only sends out a request if it's been changed. The tutorial I did for my first app went through delegates, and I can see the power. I've done event-based programming on the Android side and do embedded work professionally. I keep getting tripped up on GUI hooks of Xcode. It's more my fault for not trusting a GUI to do something text should accomplish. My pre-Reference Outlet attempt to update the button's text from the slider update involved arrowing through self.* and self.view.* for a UIButton *
|
# ? Oct 15, 2013 22:04 |
|
You can change the slider to only send an update when the user stops dragging it. Doing the networking stuff on a background thread isn't so you can send updates faster, but so that you don't hog the main thread and make the UI sluggish and/or choppy.
|
# ? Oct 16, 2013 00:01 |
|
Doc Block posted:You can change the slider to only send an update when the user stops dragging it. Doc Block posted:Doing the networking stuff on a background thread isn't so you can send updates faster, but so that you don't hog the main thread and make the UI sluggish and/or choppy. Demo worked. I was off on a bit of timing, but it turned on and whirred and beeped. After the meat of the demo I still managed to hang the firmware, but like most demo blowups I was the only one in the room to notice.
|
# ? Oct 16, 2013 01:18 |
|
How the hell does anyone deal with keyboards showing and hiding with an iOS 7 UITextView on screen? contentInset doesn't seem to do gently caress all. Pressing return hides the cursor behind the keyboard (more so than usual). What the gently caress.
|
# ? Oct 16, 2013 03:59 |
|
pokeyman posted:How the hell does anyone deal with keyboards showing and hiding with an iOS 7 UITextView on screen? contentInset doesn't seem to do gently caress all. Pressing return hides the cursor behind the keyboard (more so than usual). What the gently caress. The elegant solution of putting your UITextView in a UIScrollView and manually animating a scroll with the text view's -textViewShouldBeginEditing and -textViewShouldEndEditing methods. edit: oh, you're filling the whole screen, aren't you? The above is for a textView that can at least fit in the content area of the screen.
|
# ? Oct 16, 2013 18:02 |
|
lord funk posted:The elegant solution of putting your UITextView in a UIScrollView and manually animating a scroll with the text view's -textViewShouldBeginEditing and -textViewShouldEndEditing methods. Yeah full screen. I thought it'd be the easy case. What batshit code did they have to write for Mail.app to have a functioning text view? That'sw hat I want to know.
|
# ? Oct 16, 2013 18:22 |
|
pokeyman posted:What batshit code did they have to write for Mail.app to have a functioning text view? That'sw hat I want to know. iOS 7 Notes.app. The most complicated piece of Apple Engineering ever.
|
# ? Oct 16, 2013 19:33 |
|
lord funk posted:iOS 7 Notes.app. The most complicated piece of Apple Engineering ever. Imagine piecing that together while the Text Kit team gets it figured out. No thanks.
|
# ? Oct 16, 2013 20:31 |
|
pokeyman posted:How the hell does anyone deal with keyboards showing and hiding with an iOS 7 UITextView on screen? contentInset doesn't seem to do gently caress all. Pressing return hides the cursor behind the keyboard (more so than usual). What the gently caress. Followup: 1. contentInset works great except when you becomeFirstResponder in -viewWillAppear:, in which case your poo poo's hidden behind the keyboard. The text view obstinately animates in (e.g. when presented modally) with the text in the wrong position, so if you try to fix things by scrolling the text out from under the keyboard it looks like poo poo. Still trying to nail this one down. 2. This devforums thread is gold. A useful fix for the disappearing caret after inserting a newline at the end of the document. And a fix for caret positioning at the end of a line (keeps it at the end of the line instead of the start of the next line).
|
# ? Oct 17, 2013 00:06 |
|
pokeyman posted:2. This devforums thread is gold. A useful fix for the disappearing caret after inserting a newline at the end of the document. And a fix for caret positioning at the end of a line (keeps it at the end of the line instead of the start of the next line). quote:#14972169: iOS 7 GM UITextView: Keyboard up/down arrow keys no longer work
|
# ? Oct 17, 2013 01:07 |
|
If the phone is paired with a bluetooth audio device and I play music, does it automatically stream to it? Our MFi hasn't gone through yet so I don't have that access. But the default music player will stream to the module I'm testing. Will that still happen if I'm playing music through my app or do I need the MFi hooks?
|
# ? Oct 17, 2013 18:14 |
|
I doubt MFi matters in your circumstance. It largely depends on how you manage your audio session. Apple's starting point for AV can point you in the right direction. Stick to the higher level frameworks whenever you can.
|
# ? Oct 17, 2013 18:59 |
|
I'm confused about people starting to declare their init methods as returning instancetype because it's entirely pointless:Clang Language Extensions posted:
Am I missing something? Seems to me like people just aren't reading the docs.
|
# ? Oct 17, 2013 19:24 |
|
I see the same thing, init methods are already treated special, and they are probably doing it because they saw some library do it or in the apple docs and decided to not read about what it really is...
|
# ? Oct 17, 2013 19:49 |
|
These tableview separator lines are driving me nuts. They start out the correct color, but once you start scrolling they'll just be black. I cannot find where this is going wrong. Any ideas?
|
# ? Oct 17, 2013 20:38 |
|
pokeyman posted:I'm confused about people starting to declare their init methods as returning instancetype because it's entirely pointless: I don't like magic based on method names. Using instancedtype is more explicit with no downside.
|
# ? Oct 17, 2013 20:41 |
|
lord funk posted:These tableview separator lines are driving me nuts. They start out the correct color, but once you start scrolling they'll just be black. I cannot find where this is going wrong. Any ideas? Since you mention scrolling, look at differences between init and your prepareForReuse?
|
# ? Oct 17, 2013 20:58 |
|
Plorkyeran posted:I don't like magic based on method names. Using instancedtype is more explicit with no downside. I see where you're coming from but "magic based on method names" isn't going away. Explicit redundancy is confusing too. For example, it caused me to ask "why are people doing this?" instead of just going about my day. Do you use ARC? If so, do you annotate all of your methods with the objc_method_family attribute? If not, you're relying on "magic based on method names".
|
# ? Oct 17, 2013 21:58 |
|
Day two of pokeyman's exciting iOS 7 UITextView adventures resulted in the shoving of stuff on to GitHub. Hope someone finds it useful, and if anyone has any further fixes to contribute that'd be swell too!
|
# ? Oct 17, 2013 22:00 |
|
pokeyman posted:I see where you're coming from but "magic based on method names" isn't going away. Explicit redundancy is confusing too. For example, it caused me to ask "why are people doing this?" instead of just going about my day. The fact that that has to exist is one of the things I dislike about ARC. I don't really see that as comparable, though. The alternative to using instancetype isn't to put no return type at all and let the compiler infer it based on the name; it's putting a return type that the compiler replaces with instancetype due to the name. Why wouldn't you just put the more accurate thing there to begin with?
|
# ? Oct 17, 2013 22:10 |
|
lord funk posted:These tableview separator lines are driving me nuts. They start out the correct color, but once you start scrolling they'll just be black. I cannot find where this is going wrong. Any ideas? My separators will randomly disappear in iOS7 because who the gently caress knows!
|
# ? Oct 17, 2013 22:35 |
|
Plorkyeran posted:The fact that that has to exist is one of the things I dislike about ARC. Redundancy doesn't make things "more accurate". In this case id and instancetype are exactly as accurate because the compiler is explicitly documented as interpreting them identically. You've drawn the line at acceptable redundancy over here, I've drawn it over there. That's ok. It seems to be a matter of style, which answers my original question, so I'll leave it there. I was worried that I'd missed something about clang inferring the return type. But it seems I'm up to date.
|
# ? Oct 17, 2013 23:16 |
|
NoDamage posted:Ugh, we've been getting lots of complaints about this one: Not sure if you had a solution, but it looks like OUITextView has something of a fix. Maybe it'll help you.
|
# ? Oct 18, 2013 02:19 |
|
pokeyman posted:Redundancy doesn't make things "more accurate". In this case id and instancetype are exactly as accurate because the compiler is explicitly documented as interpreting them identically. You've drawn the line at acceptable redundancy over here, I've drawn it over there. That's ok. If you are going to have +(instancetype)sharedInstance or +(instancetype)buttsWithWiper or whatever, why not just be consistent? The compiler won't automatically figure those out based on magic method names. Yes, it is technically a style thing but I prefer the code to be explicit about return types and parameters. Plus anything that may potentially make tooling / intellisense easier is a win, although Xcode doesn't bother using any of the header info it has for Quick Help on your own code so it doesn't much matter.
|
# ? Oct 18, 2013 02:27 |
|
Ender.uNF posted:If you are going to have +(instancetype)sharedInstance or +(instancetype)buttsWithWiper or whatever, why not just be consistent? The compiler won't automatically figure those out based on magic method names. I just think it looks dumb when it's unnecessary. Like (edit: most) semicolons in JavaScript. () quote:Xcode doesn't bother using any of the header info it has for Quick Help on your own code so it doesn't much matter. I don't know what you mean here. Xcode shows my comments in Quick Help but I dunno how that relates.
|
# ? Oct 18, 2013 04:07 |
|
pokeyman posted:I just think it looks dumb when it's unnecessary. Like (edit: most) semicolons in JavaScript. I can't be sure, but I'd swear I saw some of the Apple APIs using instancetype in place of id for some init methods.
|
# ? Oct 18, 2013 04:09 |
|
|
# ? May 15, 2024 03:27 |
|
Doc Block posted:I can't be sure, but I'd swear I saw some of the Apple APIs using instancetype in place of id for some init methods. I think you're right, but unfortunately the "iOS 6.1 to iOS 7.0 API diffs" page crashes both Safari and Chrome on my iPad if I get a bit too excited and try to scroll past the first couple screenfuls, or search the page for the string "instancetype". I also remember only some frameworks doing it and not others. I don't think Foundation did. Maybe some UIKit classes did? And while I'm here, what's the deal with contentInset vs. scrollIndicatorInsets? Thanks folks, here all night.
|
# ? Oct 18, 2013 05:15 |