|
vapid cutlery posted:You can validate your app from the Xcode Organizer as well. Go to the Archives section and click the Validate button with the archive you're going to upload selected. Thanks. Unrelated: last night I figured out a good solution to a problem I was having in a dream. The human brain is weird.
|
#
?
Jun 1, 2013 18:43
|
|
|
|
| # ? May 22, 2024 07:04 |
|
|
I'm constructing a new request predicate with multiple variables, but am completely confused. "searchTerms" is an NSString. This works: code:code:EDIT: I think I found my problem. From the Apple docs: The parser does not perform any semantic type checking. It makes a best-guess effort to create suitable expressions, but—particularly in the case of substitution variables—it is possible that a runtime error will be generated. Edit: table breakage plasticbugs fucked around with this message at 07:28 on Jun 3, 2013 |
|
#
?
Jun 1, 2013 21:06
|
|
|
I think what happens is +predicateWithFormat: quotes/escapes the part you substitute in. The right way is probably creating an NSCompoundPredicate, passing in the two parts which you create using +predicateWithFormat:. What might also work is using %K instead of %@ in the format string; I'm not near a compiler right now so I can't actually check.
|
|
#
?
Jun 1, 2013 22:30
|
|
|
lord funk posted:In semi-related news, I just came across an app that clearly uses the private UITouch property _pathMajorRadius to get the finger blob size. I've been desperate to use that in TC-11 to get touch sizes for a velocity-like controller, but left it out because I figured the app would be rejected. I've written to the developer asking if he requested special treatment from Apple, or whether he just slipped it in there. No response so far. Some people on the internet recommend doing something like doing a rot13 on the string and un-doing that at runtime, or otherwise not having the selector's name compiled into your binary. Despite what other people are saying, I have actually been rejected at the human review stage for something they thought was private. We had an @selector we were getting that had the same name as something private in code for several releases, and then some reviewer with a stick sufficiently far up his rear end decided to drop the hammer. It was also something pretty benign-sounding, which made it even more irritating. Edit: Looked up the fix commit. The selector was "scale:". That was a great Friday... ultramiraculous fucked around with this message at 02:59 on Jun 2, 2013 |
|
#
?
Jun 2, 2013 02:56
|
|
|
lord funk posted:Thanks. That's actually great advice when you are stuck on a problem. The brain seems to reorganize and sort information during sleep.
|
|
#
?
Jun 2, 2013 03:19
|
|
|
ultramiraculous posted:Some people on the internet recommend doing something like doing a rot13 on the string and un-doing that at runtime, or otherwise not having the selector's name compiled into your binary. It's amazing how inconsistent the review process seems to be. And how these things always happen on Friday. We had a rejection on yesterday because Spotify was using uniqueIdentifier inside libspotify. Thankfully it happened during the validation stage. Doing a trivial encryption on the selector name is devious. I like it.
|
|
#
?
Jun 2, 2013 04:47
|
|
|
For someone with a C#/Java background, where should I start looking for an introduction to Obj-C? Are there any good options for learning the language in a Windows environment?
|
|
#
?
Jun 2, 2013 21:31
|
|
|
Above Our Own posted:For someone with a C#/Java background, where should I start looking for an introduction to Obj-C? Are there any good options for learning the language in a Windows environment? If I were you, and I was at one point, I'd just jump straight in and google stuff when you get stumped. You should have a pretty easy time getting into objective C.
|
|
#
?
Jun 2, 2013 21:50
|
|
|
Juc66 posted:If I were you, and I was at one point, I'd just jump straight in and google stuff when you get stumped. http://www.informit.com/articles/article.aspx?p=1568732 http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/Introduction/Introduction.html http://developer.apple.com/library/ios/documentation/cocoa/Conceptual/OOP_ObjC/OOP_ObjC.pdf See the literature list at the beginning of the thread for the rest and read up on things every so often.
|
|
#
?
Jun 2, 2013 22:02
|
|
|
About a year ago I jumped onto a team using Obj-C having never touched it and I went to read as much as I could beforehand to bring myself up to speed. The two best resources were the Standford iOS development lecture series on iTunes, and From C++ to Objective-C
|
|
#
?
Jun 2, 2013 22:45
|
|
|
Ugh. I just spent hours trying to make a component into its own static library. Yes, Xcode, when I put armv7, armv7s, and i386 as the target architectures that means I want you to build all 3 and put them in the same Goddamned fat binary. It doesn't mean to silently leave out i386. And when I build it in Release mode, it'd be great if you could find it in your heart to still link against it when I build my app for Debug, thanks. 
|
|
#
?
Jun 3, 2013 07:17
|
|
|
Did you succeed, and was there anything especially unintuitive about the process that might help someone else? I've only done static libraries like that for open source code by messing with configure scripts then using lipo at the end.
|
|
#
?
Jun 3, 2013 07:24
|
|
|
Yeah, it's working now. Found a little script on Stackoverflow that builds separate libraries for the device and simulator and then sticks them together with lipo. It works, but I was hoping Xcode would have this sort of thing built in. A not-insignificant chunk of time was spent poring over build settings, thinking maybe I had missed something. Then I got the bright idea to just make it a framework, but Xcode doesn't support creating frameworks for iOS out of the box. There are lots of projects (none of which seem to have updated recently) that make iOS framework templates, but a number of those involve making modifications to Xcode. Modifying Xcode seems pretty fragile and error-prone, and by this point I was ready to call it a night, so I abandoned the framework thing. I made a new aggregation target with the following script as its only action: code:
|
|
#
?
Jun 3, 2013 08:02
|
|
|
So I was staring at the Google Authenticator icon in disgust just now and thinking about how garbage that app is. Nobody seems to talk about alternatives, just Google Authenticator. So here I am thinking I'd make a purdy two-factor app and call it "something dumb, like Authy". I do a name check on iTunes, and then....seriously god dammit people. At least I don't have to figure out how to piss people off with IAPs for authenticator slots or something.
|
|
#
?
Jun 4, 2013 23:03
|
|
|
Well, Authy isn't open source. If someone added iPad support to Google Authenticator, I would be pretty pleased.
|
|
#
?
Jun 4, 2013 23:29
|
|
|
WHY IS THAT MUG USING A LAPTOP AS A COASTER
|
|
#
?
Jun 4, 2013 23:42
|
|
|
Is there a way to customize a UIAlertView with a nib? All the sample code I can find lays out the view programmatically. The best I came up with is to define my customizations to the alert (just a "don't show again" option, by the way) in a nib, load the nib from a subclass of UIView, and add an instance of my subclass as a subview of the alert e: seems to be working, except I get the switch button in the top right corner of the alert, and no text label  . Just a minor setback...
hackbunny fucked around with this message at 11:51 on Jun 5, 2013 |
|
#
?
Jun 5, 2013 11:16
|
|
|
Sooner or later you'll have to customize or create views programmatically, might as well get used to it now. But be warned, modifying stuff like UIAlertView isn't very future proof. Apple has changed the internal layout of UIAlertView in the past, and the could very likely do it again with iOS 7.
|
|
#
?
Jun 5, 2013 15:31
|
|
|
Doc Block posted:But be warned, modifying stuff like UIAlertView isn't very future proof. Apple has changed the internal layout of UIAlertView in the past, and the could very likely do it again with iOS 7. I tried to be sneaky and put my customized view in place of text input field #0, so that UIAlertView will unknowingly lay it out for me, but I can't hide the input field, in any way. Now, after reading 100% serious suggestions like "just add linefeeds at the end of your message to make room for stuff", I think I'll give up and add the "don't show again" box some other time (why isn't this standard? am I supposed to use a different UI pattern?) e: svn revert -R . 
hackbunny fucked around with this message at 16:02 on Jun 5, 2013 |
|
#
?
Jun 5, 2013 15:59
|
|
|
Could always add a button that says "OK (don't show again)" or something.
|
|
#
?
Jun 5, 2013 16:03
|
|
|
Is anyone good with random, hard-to-reproduce crashes emanating from WebCore? In desperation I'm giving web views as little to do as possible. Even downloading the relevant WebKit source and tracing the more common crashes gives me nothing to go on.
|
|
#
?
Jun 6, 2013 01:30
|
|
|
How do I put buttons in the title bar of a window like Readr?
|
|
#
?
Jun 6, 2013 02:08
|
|
|
Edit: nevermind, thought this was a different thread.
|
|
#
?
Jun 6, 2013 03:38
|
|
|
Sinestro posted:How do I put buttons in the title bar of a window like Readr? INAppStoreWindow might have some clues.
|
|
#
?
Jun 6, 2013 04:35
|
|
|
Is this really the best way to open a https://www.mywebsite.com URL in an app instead of the browser? http://stackoverflow.com/questions/1108693/is-it-possible-to-register-a-httpdomain-based-url-scheme-for-iphone-apps-like/1109200#1109200 Basically: User goes to website in mobile safari Check user agent for iPhone/iPad Check for app installed cookie - If cookie exists, and is set to true, open app with custom scheme mywebsite://blah - If cookie exists, and is set to false, load web page - If cookie doesn't exist, show a dialog with 3 options -- Yes, I have the app installed take me there --- Create cookie and set to true -- No, but I want the app (goes to app store) -- No, don't notifiy me again --- Create cookie and set to false This is so much easier on Android 
|
|
#
?
Jun 6, 2013 18:14
|
|
|
I don't know what all that complication is for. Your app registers someprotocol:// and your site redirects to a URL at that protocol.
|
|
#
?
Jun 6, 2013 18:33
|
|
|
pokeyman posted:I don't know what all that complication is for. Your app registers someprotocol:// and your site redirects to a URL at that protocol. I think the problem is he wants the application to point to http://hisappurl Which does seem to be a more complicated problem than should be necessary.
|
|
#
?
Jun 6, 2013 18:56
|
|
|
Like Youtube, I'm guessing. I can't say I've seen any other app do that. The Youtube thing was probably a byproduct of YouTube being previously bundled with the OS.
|
|
#
?
Jun 6, 2013 19:05
|
|
|
Glimm posted:I think the problem is he wants the application to point to http://hisappurl Correct. We want users to click a link in an email and have it go to the App if it's installed. If it's not, then they view our website in mobile Safari.
|
|
#
?
Jun 6, 2013 19:07
|
|
|
Doh004 posted:Correct. We want users to click a link in an email and have it go to the App if it's installed. If it's not, then they view our website in mobile Safari. There's a way I've seen this done that involves javascript timeouts on the URL request. I can't research it properly because I'm on a train with poor connection, but I'm sure there's some way of doing it so if your custom URL request (to hisappurl://) fails you can fall back to http://hisappurl.com being opened in Safari.
|
|
#
?
Jun 6, 2013 22:19
|
|
|
Froist posted:There's a way I've seen this done that involves javascript timeouts on the URL request. I can't research it properly because I'm on a train with poor connection, but I'm sure there's some way of doing it so if your custom URL request (to hisappurl://) fails you can fall back to http://hisappurl.com being opened in Safari. Yeah that's what it looks like we'll have to end up doing as well. Thanks for providing a sanity check guys. 
|
|
#
?
Jun 7, 2013 17:33
|
|
|
Is not supporting the double-height statusbar rejectionable? loving AIR is awful and trying to get it to handle FullScreen (no statusbar) and 2x height statusbar during a phone call without it either masking or resizing improperly is going to kill me, I think.
|
|
#
?
Jun 7, 2013 18:26
|
|
|
Campbell posted:Is not supporting the double-height statusbar rejectionable? loving AIR is awful and trying to get it to handle FullScreen (no statusbar) and 2x height statusbar during a phone call without it either masking or resizing improperly is going to kill me, I think. Nah. From experience, they won't reject you for it, but your app might be unusable if you've got an important button down there or something. Note that iOS6 navigation will do a double-height status bar, in addition to the phone call cases.
|
|
#
?
Jun 7, 2013 19:25
|
|
|
Yea, see with an Adobe AIR app it throws a subview into the RootViewController but is otherwise untouchable by iOS except through events dispatched back into flash. That view, regardless of how I try to adjust it from IOS doesn't like to listen to autoresize properties, so I'm resorted to just trying to manually place it at y=0 or y=40 depending on if the bar is on or off. I've been experimenting with using the StatusBarWillChange, DidEnterBackground, DidEnterForeground events to detect when a double-height bar is shown, and that seems fine. But sometimes it'll end up cropping the subview, or stretching it unexpectedly, like when the Native IOS Camera is used. Resetting the frame size of the root view (and subviews) is just as spotty in those cases. Anyways, if it won't outright get us rejected, I almost think not having the phone bar is better than having it be ok except in a few cases. I'm just a dev though, so who knows how that'll fly.
|
|
#
?
Jun 7, 2013 20:07
|
|
|
Campbell posted:Yea, see with an Adobe AIR app it throws a subview into the RootViewController but is otherwise untouchable by iOS except through events dispatched back into flash. That view, regardless of how I try to adjust it from IOS doesn't like to listen to autoresize properties, so I'm resorted to just trying to manually place it at y=0 or y=40 depending on if the bar is on or off. Not on my mac at the moment, but I wonder if it would be possible to use KVO to observe a property (such as frame) of the root view, window, or view controller, then send a notification into the AIR part of your app, using whatever mechanism you have available.
|
|
#
?
Jun 7, 2013 20:12
|
|
|
Campbell posted:Yea, see with an Adobe AIR app it throws a subview into the RootViewController but is otherwise untouchable by iOS except through events dispatched back into flash. That view, regardless of how I try to adjust it from IOS doesn't like to listen to autoresize properties, so I'm resorted to just trying to manually place it at y=0 or y=40 depending on if the bar is on or off. Option A: Does the AIR App give you a root view controller? What's supposed to happen is you have a view controller associated with your window. You'd basically do "[window setRootViewController:AIRViewController]" somewhere in your AppDelegate startup process, and iOS is supposed to take care of the rest. Option B: You at least have an app delegate, right? Back when I didn't realize I had forgotten to do Option A, I had this code set up to deal with status bar changes: code:
|
|
#
?
Jun 7, 2013 22:17
|
|
|
Say my app is using two keys that one of our SaaS web services provides us with, and they're basically a couple of string consts in the code. How likely is someone to get hold of those keys, assuming they're always passed around over HTTPS? I know that AppStore binaries are supposedly encrypted (does this apply to In-House distributions?), but I imagine someone at some point figured out how to decrypt those after rooting the phone and downloading the IPA. Is that true? My issue is that we don't really have proper ACLs in place yet because of both UX reasons and lack of time, so I'm trying to understand how long we have before someone jacks the keys and downloads our entire data set. To pre-empty criticism, the current security-by-obscurity state is unquestionably terrible, so I'm just trying to figure out how much of a burning issue this is.
|
|
#
?
Jun 10, 2013 05:36
|
|
|
Maybe just store the keys XORed in your code and then unXOR them at runtime. Otherwise, anybody who bothers to run strings on your binary will find the keys.
|
|
#
?
Jun 10, 2013 07:35
|
|
|
DreadCthulhu posted:Say my app is using two keys that one of our SaaS web services provides us with, and they're basically a couple of string consts in the code. How likely is someone to get hold of those keys, assuming they're always passed around over HTTPS? I know that AppStore binaries are supposedly encrypted (does this apply to In-House distributions?), but I imagine someone at some point figured out how to decrypt those after rooting the phone and downloading the IPA. Is that true? It might be worth obfuscating the constants and decrypting them at runtime. And yes, my understanding is that the app binary can be easily decrypted on a jailbroken device. Also, nothing else in the IPA is encrypted as a result of App Store distribution, just the binary. Dunno about in-house distribution. HTTPS is irrelevant if users can install certs on the device, they can watch all the traffic by MITMing themselves. The real answer is to fix your app's interaction with the relevant services, which you appear to already know, so maybe get on that.
|
|
#
?
Jun 10, 2013 07:45
|
|
|
|
| # ? May 22, 2024 07:04 |
|
|
Doc Block posted:Maybe just store the keys XORed in your code and then unXOR them at runtime. Otherwise, anybody who bothers to run strings on your binary will find the keys. They'd have to decrypt the binary first.
|
|
#
?
Jun 10, 2013 07:46
|
|