|
This one stumped me for an hour or so today. Ultimately, I think this is a case where Apple is technically correct but is doing something dumb. We got a report that searches containing the quotation mark character aren't returning results in our iOS app. This was baffling, because both our website and our Android application, which uses the same web service, work just fine. The problem turned out to be that when using the Hebrew keyboard in iOS, Apple maps the quotation mark key to unicode U+05F4, "Hebrew Punctuation Gershayim". In the real world, pretty much every computer application is using the good old ASCII quotation mark character, and the only people who care about the tiny visual difference between the two characters are typesetters and designers. Apple's own OS X Hebrew keyboard layout uses the regular quotation mark, as do Windows and Android. I'm sure our application isn't the only one broken by this.
|
#
?
Jul 4, 2013 13:30
|
|
|
|
| # ? May 15, 2024 15:18 |
|
|
Has anybody messed around with app ownership transfers yet? I've recently migrated an app to a different account and noticed that its in-app-purchases are no longer showing up in the app store version. They show up just fine under Simulator though, but I can't run the app on a device yet because the new account has no signing key nor a single provisioning profile :| I imagine that might be part of the issue? It's an odd situation because the new account has apps in the App Store in it, but it also has no keys or profiles. I imagine you're expected to create new ones for the same apps, which sounds like a giant PITA if you have many apps.
|
|
#
?
Jul 5, 2013 02:18
|
|
|
On an unrelated note, is there a replacement for the UIDevice's uniqueIdentifier method that would return the same exact value? The guy who wrote the first draft of an app I'm working with now has made sure to make uniqueIdentifier the primary key for every single user and use that to keep track of IAPs, scores, user-generated submissions etc. Basically if I don't have that value, I can't find out anything about the user from the api we're using. Apple also decided not to let you submit code with that call in it anymore, which is reasonable since they were complaining about its deprecation for over a year.
|
|
#
?
Jul 5, 2013 04:16
|
|
|
DreadCthulhu posted:On an unrelated note, is there a replacement for the UIDevice's uniqueIdentifier method that would return the same exact value? Nope, they didn't just rename the method. It's gone.
|
|
#
?
Jul 5, 2013 04:53
|
|
|
Be slightly wary of using MKStoreKit, it's accumulated over 80 issues and 16 pull requests at this point and was updated last 5 months ago. Apple won't accept anything committed with it, because of deprecated API use similar to what I mentioned above, unless you make a manual fix to some of the code. I've used it fine myself, but you probably want to dig through the code make sure you understand it.
|
|
#
?
Jul 5, 2013 08:35
|
|
|
DreadCthulhu posted:On an unrelated note, is there a replacement for the UIDevice's uniqueIdentifier method that would return the same exact value? There's an identifierForVendor that's basically the same concept. It's different from app to app, and from device to device. It's a really poo poo way to identify users, though, because you're guaranteed to "lose" the user if they get their device replaced. Use the GameKit identifier or something. Also apps in the store already using uniqueIdentifier in the app store are gonna start reporting a completely different value as of iOS 7. It's the deviceIdentifier padded with Fs, if I remember correctly.
|
|
#
?
Jul 5, 2013 15:50
|
|
|
I just submitted a UI/Usability request through the bug reporter for UIPopoverController screen dimming to have a toggle. The new behavior in 7 automatically dims the screen behind it, but that doesn't make sense when the popover allows for user interaction (adding views to its 'passthroughViews' property). The dimming makes sense for an alert view, because it really is the sole focus when it appears. But if you have a popover that allows for interaction behind it, it's sending the wrong message.
|
|
#
?
Jul 5, 2013 17:32
|
|
|
orenronen posted:This one stumped me for an hour or so today. Ultimately, I think this is a case where Apple is technically correct but is doing something dumb. Your web service doesn't handle Unicode input properly. You can try CFStringTransform with kCFStringTransformToLatin but I don't know that it translates that punctuation mark. However that's a terrible idea because then you get inconsistent results between platforms. Your web service should be doing a conversion to normalized forms. This applies to indexing, lookups, hash tables in many cases, etc. Whatever the case, you should be matching the same record whether the user types in "中文" vs "zhōng wén", or "resumè" vs "resume". There are also multiple ways to encode stuff like diacritics so if you aren't normalizing those strings that appear identical will in fact be byte-different; bonus points for coworkers who don't know and mix ordinal, invariant, and culture-aware string comparisons. Punctuation marks also have equivalency categories, in this case "Punctuation - Final" and "Puctuation - Initial" though for our cases they can generally be considered the same. Depending on the situation this is also a great way to introduce massive security holes or bugs when the values are primary keys, usernames, passwords, etc. For example, converting a UTF-16 password to bytes for hashing using ASCII, which will spit out the unknown character code point for everything not in the basic lower ASCII set, or worse map it to the system code page for the upper characters in which case a bunch of French, Chinese, Japanese, etc people get to unknowingly share the same password regardless of what they type in. Every string comparison should be checked for the kind of comparison you want to do and noted as having been reviewed (eg: usernames compared invariant normalized so they are treated identically no matter who input them, with what keyboard, etc). Same deal for any output to a file/stream, hashing, etc. Edit: for some insane reason that Hebrew quote is listed in the "Puctuation - Other" category. Unicode is hard, mostly because humans are easily offended tribalistic assholes. Simulated fucked around with this message at 19:29 on Jul 5, 2013 |
|
#
?
Jul 5, 2013 19:24
|
|
|
lord funk posted:I just submitted a UI/Usability request through the bug reporter for UIPopoverController screen dimming to have a toggle. The new behavior in 7 automatically dims the screen behind it, but that doesn't make sense when the popover allows for user interaction (adding views to its 'passthroughViews' property). I think it's a question of intent. Pass through view is basically there to allow the user to dismiss the popover with the same button they brought it up with. Popovers are modal in intent: you interact with the popover only while it is onscreen according to my reading of the HIG. Dimming visually reinforces this. Maybe things changed in 6 or something, but that dimming behavior seems fine to me, since popovers are meant to be quickly used then dismissed.
|
|
#
?
Jul 5, 2013 22:35
|
|
|
Lumpy posted:I think it's a question of intent. Pass through view is basically there to allow the user to dismiss the popover with the same button they brought it up with. Popovers are modal in intent: you interact with the popover only while it is onscreen according to my reading of the HIG. Dimming visually reinforces this. Maybe things changed in 6 or something, but that dimming behavior seems fine to me, since popovers are meant to be quickly used then dismissed. I'm not so sure. iOS 6.1 HIG posted:Popovers and modal views are similar, in the sense that people typically can’t interact with the main view while a popover or modal view is open. But a modal view is always modal, whereas a popover can be used in two different ways: I see nothing to counter this in the iOS 7 HIG. The position seems to consistently avoid framing popovers as strictly modal views. (Obviously, whether the UIPopoverController class functions according to the HIG is another question entirely. If it doesn't, that's a bug in either the class or the HIG.)
|
|
#
?
Jul 5, 2013 23:30
|
|
|
pokeyman posted:I'm not so sure. Yeah, it is kind of vague, but even the non-dimming non-modal description you quoted states that tapping anywhere outside of the popover should dismiss it. To me that reads as "while the popover is up, you either interact with it or get rid of it when you tap anywhere outside of it." I guess there are use cases for not wanting dimming to see the results of actions in the popover (like color picker for font or something) without the fade interfering, but the 'leave the popover up while you use the app' case still seems sketchy to me, and reading what you quoted reinforces that. So, yes, there probably be a non-dimming option, but not for the reasons lord funk wants it. 
|
|
#
?
Jul 6, 2013 06:42
|
|
|
Lumpy posted:Yeah, it is kind of vague, but even the non-dimming non-modal description you quoted states that tapping anywhere outside of the popover should dismiss it. To me that reads as "while the popover is up, you either interact with it or get rid of it when you tap anywhere outside of it." UIPopoverController Class Reference posted:When displayed, taps outside of the popover window cause the popover to be dismissed automatically. To allow the user to interact with the specified views and not dismiss the popover, you can assign one or more views to the passthroughViews property. Taps inside the popover window do not automatically cause the popover to be dismissed. Your view and view controller code must handle actions and events inside the popover explicitly and call the dismissPopoverAnimated: method as needed.
|
|
#
?
Jul 6, 2013 14:44
|
|
|
Lumpy posted:Yeah, it is kind of vague, but even the non-dimming non-modal description you quoted states that tapping anywhere outside of the popover should dismiss it. To me that reads as "while the popover is up, you either interact with it or get rid of it when you tap anywhere outside of it." I guess there are use cases for not wanting dimming to see the results of actions in the popover (like color picker for font or something) without the fade interfering, but the 'leave the popover up while you use the app' case still seems sketchy to me, and reading what you quoted reinforces that. The HIG doesn't say "popovers are modal". You're extrapolating, and in fact I largely agree with you, but that's not canonical HIG. lord funk posted:The class reference is pretty clear that it's okay to allow for touches outside the popover: Well, no, the class reference is pretty clear that it's possible to allow for touches outside the popover. Doesn't mean it's a good idea!
|
|
#
?
Jul 6, 2013 17:29
|
|
|
pokeyman posted:Well, no, the class reference is pretty clear that it's possible to allow for touches outside the popover. Doesn't mean it's a good idea! Right, but we're getting pretty pedantic here. In my case people want to continue playing the instrument while they look for the next patch. That's a good reason not to dismiss the popover with touches outside the popover. In other news I'm tired of collection views again. Go home, cell; you are drunk.
|
|
#
?
Jul 7, 2013 01:52
|
|
|
Hopefully this is the right place for a homebrew question: I've set up a formula after forking someone else's and I'm having difficulty getting a test to run correctly - the problem is pretty self explanatory at https://github.com/Bozart/homebrew-mono/blob/master/mono.rb Basically I try to compile and run a hello world in mono but it errors out, and it doesn't help that I am completely clueless in ruby, homebrew, and osx in general. Also I think the same problem exists in the go lang formula, because I get an error with that one's test as well, and that's where I got the hello world test code from. So what am I doing wrong in the mono formula? brew install mono --devel works correctly, and that's all I'm working on right now.
|
|
#
?
Jul 7, 2013 03:55
|
|
|
Have you tried compiling it from scratch and running the test outside of homebrew? quote:Prerequisite: the OSX build expects autotools and dependency libraries from Xcode's standard toolchain. If you have macports or fink installed, disable them when you are building mono. (e.g. remove /opt/local/bin Homebrew fits that bill. Are you specifically trying to make it work with homebrew for some reason? also line 39: code:code:DONT THREAD ON ME fucked around with this message at 05:54 on Jul 7, 2013 |
|
#
?
Jul 7, 2013 05:37
|
|
|
When it comes to installing language platforms I tend to prefer to go outside of homebrew - though don't get me wrong, it's great for all kinds of open-source projects. Consider installing mono from outside homebrew, using whatever installation packages are officially provided.
|
|
#
?
Jul 7, 2013 07:08
|
|
|
edit: n/m
kitten smoothie fucked around with this message at 05:54 on Jul 8, 2013 |
|
#
?
Jul 8, 2013 05:46
|
|
|
I found this on a design blog, but seems very appropriate to post here: Teehan-Lax posted about messing with collection view in a calendar app named Upcoming, which they created to explore UI stuff. That in and of itself is pretty cool but they talk about Reactive Cocoa which seems pretty interesting and / or cool.
|
|
#
?
Jul 8, 2013 18:00
|
|
|
I haven't actually written anything that uses ReactiveCocoa yet, but the one question in my mind when reading about it last year was "how does this work with collection/table views?" I don't have a complete answer but "a signal that delivers arrays" had eluded me.
|
|
#
?
Jul 8, 2013 21:20
|
|
|
pokeyman posted:I haven't actually written anything that uses ReactiveCocoa yet, but the one question in my mind when reading about it last year was "how does this work with collection/table views?" I don't have a complete answer but "a signal that delivers arrays" had eluded me. Teehan+Lax open sourced all their code for that app, so go find out!
|
|
#
?
Jul 8, 2013 21:50
|
|
|
Lumpy posted:Teehan+Lax open sourced all their code for that app, so go find out! That's what I was looking at. Makes sense for collections that don't change much, but my complete answer would basically include the ReactiveCocoa equivalent of NSFetchedResultsController. Someday I'll actually make something with ReactiveCocoa and figure it out!
|
|
#
?
Jul 8, 2013 22:25
|
|
|
I have two questions about iAds: I have written interactive javascript code that pans the 'camera' around a quasi-3D jpg image. I have gotten this code to appear in my iAd, but I do not know if Apple will accept the way I have done it. 1. The initial 'Banner' portion: iAd Producer only provides widgets for images, text, and 'view'. However, exported iAds are just HTML and .js files. I have hand-edited the banner files and I have added javascript to them, to display my 3D effect in the banner. Is this allowed? 2. The 'Main Page' ad section: I was able to import all of my javascript files into iAd Producer, and use the 'HTML' widget to create my 3D scene. However, iAd has written the javascript file includes in the incorrect order. I hand-edited the index.html file to correct this. Will this be allowed?
|
|
#
?
Jul 9, 2013 16:29
|
|
|
Just to be sure, if I want to write a little app for myself that serves as a private tracking beacon and run it on (pretty much) only my iPhone, my only option is a developer account, correct?
|
|
#
?
Jul 10, 2013 02:11
|
|
|
movax posted:Just to be sure, if I want to write a little app for myself that serves as a private tracking beacon and run it on (pretty much) only my iPhone, my only option is a developer account, correct? The $100 iOS Developer Program membership is what you want. (Or I should say "need"; it's pretty lame that you need to fork out $100 to put just your app on just your phone.)
|
|
#
?
Jul 10, 2013 02:23
|
|
|
pokeyman posted:The $100 iOS Developer Program membership is what you want. (Or I should say "need"; it's pretty lame that you need to fork out $100 to put just your app on just your phone.) $100 a year for that privilege  Early access to iOS / OSX betas though I guess.But, I don't have to deploy it publicly, that just gives me the power to run whatever apps I create on my own iPhone / any other UUIDs I add as a tester or something?
|
|
#
?
Jul 10, 2013 02:31
|
|
|
movax posted:$100 a year for that privilege Just iOS. OS X betas are another $100 a year. quote:But, I don't have to deploy it publicly, that just gives me the power to run whatever apps I create on my own iPhone / any other UUIDs I add as a tester or something? With the $100 membership you can deploy any number of apps on up to 100 different devices. Submitting an app to the App Store (aka deploying your app publicly) is an entirely optional, separate process.
|
|
#
?
Jul 10, 2013 02:56
|
|
|
I've not tried it, but it seems like if you jailbreak you can do some monkeying with Xcode to get it to install and run things with invalid signatures (paying Apple a C-note gets you the signing key to deploy to your own device). So maybe that's an option if you're not above jailbreaking and you only care about running this on your phone and not anyone else's. http://iphonedevwiki.net/index.php/Xcode#Developing_without_Provisioning_Profile
|
|
#
?
Jul 10, 2013 03:09
|
|
|
pokeyman posted:Just iOS. OS X betas are another $100 a year. Should be noted that you also get the final releases of OS X for free, though that admittedly has a little less value now that they're only $20.
|
|
#
?
Jul 10, 2013 21:04
|
|
|
movax posted:Just to be sure, if I want to write a little app for myself that serves as a private tracking beacon and run it on (pretty much) only my iPhone, my only option is a developer account, correct? Or use Find My iPhone.
|
|
#
?
Jul 11, 2013 07:54
|
|
|
I've been doing iOS development for coming up on a year now, and I still haven't found a good way to do dynamically sized UITableViewCell's that doesn't involve prerendering the cell to get its height before cellForRowAtIndexPath. Am I missing something super obvious here?
|
|
#
?
Jul 11, 2013 16:55
|
|
|
Shouldn't you be able to compute it based on certain metrics? You can find out how big the text will be, plus the sizes of any other elements, so that + the top and bottom margins = cell height.
|
|
#
?
Jul 11, 2013 17:59
|
|
|
Doh004 posted:I've been doing iOS development for coming up on a year now, and I still haven't found a good way to do dynamically sized UITableViewCell's that doesn't involve prerendering the cell to get its height before cellForRowAtIndexPath. Am I missing something super obvious here? Use NSString's -sizeWithFont: and similar methods to figure out text size. Everything else should already have its height available to you.
|
|
#
?
Jul 11, 2013 18:25
|
|
|
Doc Block posted:Shouldn't you be able to compute it based on certain metrics? You can find out how big the text will be, plus the sizes of any other elements, so that + the top and bottom margins = cell height. This is basically my pattern, but I do the calculation in a class method on my cell subclass. That way you can share internal constants (font sizes, padding, etc) without having to expose them in the header. In any controller that uses the cell it's as returning [SomeCell heightForObject:someModelObject].
|
|
#
?
Jul 11, 2013 18:26
|
|
|
bumnuts posted:This is basically my pattern, but I do the calculation in a class method on my cell subclass. That way you can share internal constants (font sizes, padding, etc) without having to expose them in the header. In any controller that uses the cell it's as returning [SomeCell heightForObject:someModelObject]. That's a good idea. And if you're like me and prefer to keep your cells oblivious to your models, your method can be something like +[Cell heightForCellWithText:width:].
|
|
#
?
Jul 11, 2013 18:33
|
|
|
Just remember that NSString+UIKit's method -sizeWithFont:forWidth:lineBreakMode: is broken (only returns the width, the height is always returned as the height of one line regardless of how many lines it would actually take), and has been broken forever. Apple doesn't seem to care about fixing it. Instead, use -sizeWithFont:constrainedToSize:lineBreakMode: instead, with the height of the size constraint set to something reasonable.
|
|
#
?
Jul 11, 2013 18:41
|
|
|
Doc Block posted:Shouldn't you be able to compute it based on certain metrics? You can find out how big the text will be, plus the sizes of any other elements, so that + the top and bottom margins = cell height. I have custom cells that have more than just text - bunch of subviews. I also reuse the cells for performance reasons. The issues comes from the fact that once a cell is queued, its heightForRowAtIndexPath is never called again. So the first time it loads, I could calculate its height just fine by myself, but as I'm scrolling down and it gets reused, it'll reuse the old height. Could you call reloadRowsAtIndexPaths:<#(NSArray *)#> withRowAnimation:<#(UITableViewRowAnimation)#> while scrolling? I feel like that'd be a big performance hit.
|
|
#
?
Jul 11, 2013 19:02
|
|
|
Doh004 posted:I have custom cells that have more than just text - bunch of subviews. I also reuse the cells for performance reasons. The issues comes from the fact that once a cell is queued, its heightForRowAtIndexPath is never called again. So the first time it loads, I could calculate its height just fine by myself, but as I'm scrolling down and it gets reused, it'll reuse the old height. That's not right. The table view will call -tableView:heightForRowAtIndexPath: as you scroll regardless of whether you reuse cells. Are you sure that method is not called on your delegate as you scroll?
|
|
#
?
Jul 11, 2013 19:28
|
|
|
pokeyman posted:That's not right. The table view will call -tableView:heightForRowAtIndexPath: as you scroll regardless of whether you reuse cells. Are you sure that method is not called on your delegate as you scroll? I think you're partially right? It gets called when you set the data source and reloadData gets called for all of the rows, even ones that aren't visible yet. At least that's what I'm currently seeing with my NSLogs.
|
|
#
?
Jul 11, 2013 19:38
|
|
|
|
| # ? May 15, 2024 15:18 |
|
|
So just calculate it then.
|
|
#
?
Jul 11, 2013 20:00
|
|