|
eschaton posted:No they won't. Set your deployment target to iOS 5.1, and any 6.0 classes will be weak-linked and show up as nil at runtime on an iOS 5.1 device. Any of your own subclasses of a 6.0 class will be similarly nil on an iOS 5.1 device. This has been the case since at least iOS 3.2. (And on OS X since 10.6.8.) You are correct; this became feasible on iOS 4.2 apparently. Prior to that you had to weak-link entire frameworks, which against something like UIKit made your app horribly, horribly slow. As of the newer SDKs it will automatically weak-link just the missing classes, which is news to me. I still don't think the effort of supporting older OSes is worth it in most cases but YMMV.
|
#
?
Jan 6, 2013 16:03
|
|
|
|
| # ? May 21, 2024 00:12 |
|
|
Froist posted:Also the Apple WWDC talks are all available to developers through iTunes if you haven't seen them. They're generally very good but tend to labour the basics a little too much for me, that could be what you need to pick up the design patterns though? Watch them on iTunes U at 2x speed. You won't miss anything except for one woman presenter goes a bit too fast at 2x, had to drop that down to 1.5 when she's speaking.
|
|
#
?
Jan 6, 2013 17:28
|
|
|
How bad are memory warnings? Is it one of those things where I should drop whatever I'm doing and figure out how to have the app avoid it at all costs, or is it an absolutely normal part of a beefy app's existence? "Depends"?
|
|
#
?
Jan 7, 2013 02:36
|
|
|
A lone memory warning here and there isn't generally something to worry about, especially for a big app, and doesn't mean there is something wrong with the app. It just means that available memory is getting low and your app should do what it can to reduce its memory usage (unload things that can be reloaded/recreated later). Of course, iOS might very well terminate your app if enough memory doesn't get freed up, but it seems it tries to kill background apps before killing the foreground app. Doc Block fucked around with this message at 03:20 on Jan 7, 2013 |
|
#
?
Jan 7, 2013 03:07
|
|
|
I doubt it's even possible to entirely avoid ever getting memory warnings; if there's only a few MB of ram available when your app is started, then you're going to get a memory warning before you've even done much of anything. You should try to keep memory usage down to avoid killing background apps as much as possible, but getting a memory warning is not at all a big deal.
|
|
#
?
Jan 7, 2013 03:18
|
|
|
Great, thanks! Quick question about image asset size. Do you all apply the various size-shrinking transformations such as Photoshop's "Save for Web" and "Posterize" (or perhaps through PNGcrush) to your image assets to bring their volume down to a bare minimum? I've literally never done that to any of my images and the total amounts to 1.5M. I don't know if it makes a huge difference, but I imagine it could. Feels like I'm coding for a 1980 GameBoy here.
|
|
#
?
Jan 7, 2013 03:45
|
|
|
DreadCthulhu posted:Great, thanks! I think Xcode does this for you (for PNGs) when you build your project.
|
|
#
?
Jan 7, 2013 03:48
|
|
|
Built 4 Cuban Linux posted:I think Xcode does this for you (for PNGs) when you build your project. Oh yeah it does look like it. "Compress PNG Files" under Build Settings -> Packaging.
|
|
#
?
Jan 7, 2013 03:53
|
|
|
I get much smaller pngs from something like ImageOptim than I do from Xcode. Xcode does give it a try though.
|
|
#
?
Jan 7, 2013 06:10
|
|
|
AFAIK Xcode just converts the PNGs into a GPU-friendly pixel format so that no conversion needs to be done at runtime, not necessarily going for minimum file size. Using ImageOptim will get the file size down, but with possibly slower load times, because IM will try every pixel format PNG supports (including 8-bit), and the device will have to convert it back to something the GPU can use when the image is loaded. Doc Block fucked around with this message at 07:18 on Jan 7, 2013 |
|
#
?
Jan 7, 2013 07:10
|
|
|
Doc Block posted:AFAIK Xcode just converts it into a PNG format that's more quickly loaded, not necessarily going for minimum file size. Using ImageOptim will get the file size down, but with possibly slower load times since the resulting image will most likely have to be converted to a pixel format usable by the GPU after being loaded and uncompressed. Yeah, the big thing it does is convert from RGBA to ARGB, which is the byte order the device prefers. Additionally: pokeyman posted:I get much smaller pngs from something like ImageOptim than I do from Xcode. Xcode does give it a try though.
|
|
#
?
Jan 7, 2013 07:16
|
|
|
A Bloody Crowbar posted:I did this for one product and vowed never again. I have read Chris's comments and was once persuaded by them, but I'm no longer sure there's an advantage in making the distinction between properties and behavior; all you should need to know is that the method returns something. One iOS developer at Apple told me they don't use dot syntax because it looks like struct access. I realize though that this is a years-old old conversation topic and was just curious.
|
|
#
?
Jan 7, 2013 10:27
|
|
|
Doc Block posted:AFAIK Xcode just converts the PNGs into a GPU-friendly pixel format so that no conversion needs to be done at runtime, not necessarily going for minimum file size. Possibly slower load times, when exactly?
|
|
#
?
Jan 7, 2013 10:41
|
|
|
Toady posted:One iOS developer at Apple told me they don't use dot syntax because it looks like struct access. Did they clarify why it's important to them to distinguish between struct access and sending a message to an instance? I can't tell if I'm surprised to hear that internal code doesn't look like code in the documentation. I nearly always see dot notation.
|
|
#
?
Jan 7, 2013 11:07
|
|
|
DreadCthulhu posted:Possibly slower load times, when exactly? When the image is loaded at run time. Or, if the OS doesn't convert it when the image is first loaded, then when you assign it to a UIImageView.
|
|
#
?
Jan 7, 2013 11:22
|
|
|
Doc Block posted:When the image is loaded at run time. Or, if the OS doesn't convert it when the image is first loaded, then when you assign it to a UIImageView. Sounds good, thanks. Still not sure if it's worth the trade-off though, assuming XCode doesn't actually resize them in any meaningful way. On a separate note, how do people here test version to version updates? Checking out different commits in git and applying those works ok at best (and is not 100% approved by apple, they want you to update through ad-hoc ipa in iTunes), but sucks way more when XCode needs to be restarted between the checkouts. That happens to me when there are major changes in the project file between different versions, such as targets and schemes being added/removed.
|
|
#
?
Jan 7, 2013 13:57
|
|
|
pokeyman posted:Did they clarify why it's important to them to distinguish between struct access and sending a message to an instance? He didn't clarify, and I don't know if he'd care if his name was given out, but it's someone who has given WWDC presentations. I'm sure Apple engineers are like any other engineers and have personal preferences that don't represent an official policy. Edit: Looking back at my words, "they" was meant to refer only to this engineer, not to the iOS development team. Toady fucked around with this message at 19:38 on Jan 7, 2013 |
|
#
?
Jan 7, 2013 19:35
|
|
|
DreadCthulhu posted:Still not sure if it's worth the trade-off though, assuming XCode doesn't actually resize them in any meaningful way. Just to be clear, the trade-off here is install footprint vs. runtime performance. As for memory usage, the XCode way likely has lower peak memory consumption and equivalent steady state consumption. Edit: DreadCthulhu posted:Feels like I'm coding for a 1980 GameBoy here. If your minimum supported iOS version is 5.0+, you're running on a device with at least 256MB of RAM, of which you can potentially use as much as 100MB. If you've only got 1.5MB of resources, it's a pretty safe bet that you're worrying over nothing. You can run your app in Instruments and easily see just how much memory you actually are using, if you need reassurance. Zhentar fucked around with this message at 21:44 on Jan 7, 2013 |
|
#
?
Jan 7, 2013 21:32
|
|
|
Is there any way to get the iOS 4 simulator and SDKs from apple or do I have to use 
|
|
#
?
Jan 8, 2013 01:32
|
|
|
If you have a developer account you can download old versions of Xcode from the developer download area.
|
|
#
?
Jan 8, 2013 01:35
|
|
|
Zhentar posted:If your minimum supported iOS version is 5.0+, you're running on a device with at least 256MB of RAM, of which you can potentially use as much as 100MB. If you've only got 1.5MB of resources, it's a pretty safe bet that you're worrying over nothing. You can run your app in Instruments and easily see just how much memory you actually are using, if you need reassurance. I always keep my apps below 20MB for over-the-air downloading, but I just checked and they bumped that up to 50MB. So long Save for Web.
|
|
#
?
Jan 8, 2013 02:02
|
|
|
Toady posted:I'm sure Apple engineers are like any other engineers and have personal preferences that don't represent an official policy. I do love coming across an obscure piece of documentation where someone uses their special snowflake style.
|
|
#
?
Jan 8, 2013 02:37
|
|
|
Zhentar posted:If your minimum supported iOS version is 5.0+, you're running on a device with at least 256MB of RAM, of which you can potentially use as much as 100MB. If you've only got 1.5MB of resources, it's a pretty safe bet that you're worrying over nothing. You can run your app in Instruments and easily see just how much memory you actually are using, if you need reassurance. Fair enough. I remember reading at some point that there was an actual memory cap for apps before they got killed, somewhere around 50mb or so, but that might have been a couple of years ago. I do agree that it makes much more sense for that cap not to be hard, but to depend on the resource availability of the OS, so I'm sure that's how it actually works. In any case, I'm thinking that a lot of my memory warnings come from the fact that I do really heavy Core Data DB population when I run the app the very first time and so a ton of the data must be still cached in memory. Based on what I read Core Data is pretty smart and autonomous as far as managing cache size is concerned, and so it simply waits to wipe the cache until it receives a memory warning. Now that I think of it, this should be somewhat testable through instruments by simulating a memory warning.
|
|
#
?
Jan 8, 2013 03:13
|
|
|
Is it possible to test in-app purchases without wi-fi? I could have sworn that I'd read somewhere that you could do it with a physical iPad connected to the computer with a USB cable, but I'm not sure how to make it work since I don't have an internet connection on the iPad itself that way.
|
|
#
?
Jan 8, 2013 04:17
|
|
|
Probably not, unless the iPad can do internet connection sharing over USB (which I don't think it does).
|
|
#
?
Jan 8, 2013 04:48
|
|
|
Brent Simmons posted this months-old comparison of iOS image loading times, which seems to show file size is more important than byte order, and that Xcode doesn't do that great. Forgot all about this. Of course, run your own tests for your app to see what works best for you.
|
|
#
?
Jan 8, 2013 06:15
|
|
|
pokeyman posted:Brent Simmons posted this months-old comparison of iOS image loading times, which seems to show file size is more important than byte order, and that Xcode doesn't do that great. Forgot all about this. Of course, run your own tests for your app to see what works best for you. drat, those are some good numbers. I'm going to give that a try and see.
|
|
#
?
Jan 8, 2013 06:43
|
|
|
Is there a reasonable upper limit to how much I can stuff in NSUserDefaults? I don't want to have to re-implement an archived NSDictionary by hand, or Core Data for that matter, if that's already been done for me. I'd at most store one integer for probably up to a thousand entries with a UUID as key. Doesn't sound like a lot to me, but it'd still be nice to know if there's a point at which either NSUserDefaults will reject more entries or have performance degradation or more side-effects. I couldn't find any reasons for not abusing that system.
|
|
#
?
Jan 8, 2013 07:43
|
|
|
Toady posted:I have read Chris's comments and was once persuaded by them, but I'm no longer sure there's an advantage in making the distinction between properties and behavior; all you should need to know is that the method returns something. One iOS developer at Apple told me they don't use dot syntax because it looks like struct access. I realize though that this is a years-old old conversation topic and was just curious. I would argue that there's an important difference, worthy of syntactic distinction where possible, between computational operations and imperative ones. It is impossible for a language (modulo massive invasion of concerns à la Haskell) to prevent you from taking a feature designed for arbitrary computation and using it for imperative tasks, and to force you to cautiously sort every last action into one of two piles is ultimately to waste your time, but to allow you to naturally communicate this in a prevalent case while making your code more concise seems to me a straightforward win. I understand the argument about complexity of operations — that I should be able to look at code and know immediately what is expensive or complex — but disagree on several levels. First, that it is challenging to immediately know what's a property access and what isn't: a well-named property or variable should make its approximate type obvious enough. Second, that the complexity is hard to place: anyone familiar enough with an operation to analyze it like this should find it easy enough to guess at what would need to be done to carry it out, and those guesses are simple to verify in an IDE. And third, that this is even a reasonable way to approach optimization: staring at written code and imagining places to cut, rather than uncovering your actual costs and finding new ways to avoid them. Code should suggest its complexity; the only thing dot-syntax obscures is whether a value is cached or not, and if that caching matters that much, there is an appropriate solution. And I say all this as a compiler writer who regrets every last spurious message-send.
|
|
#
?
Jan 8, 2013 09:05
|
|
|
Is PyObjC still a thing with Xcode4? I heard there were some major incompatibilities with the new IB replacement if you wanted to add a GUI to Python. I have a Python thing I really just want to throw a quick menubar GUI onto without rewriting the whole thing in ObjC.
|
|
#
?
Jan 8, 2013 15:01
|
|
|
Spotted in my code today. It's always good to comment your work, kids!
|
|
#
?
Jan 8, 2013 17:34
|
|
|
i am well acquainted with temporal commenting myself
|
|
#
?
Jan 8, 2013 21:57
|
|
|
rjmccall posted:I would argue that there's an important difference, worthy of syntactic distinction where possible, between computational operations and imperative ones. It is impossible for a language (modulo massive invasion of concerns à la Haskell) to prevent you from taking a feature designed for arbitrary computation and using it for imperative tasks, and to force you to cautiously sort every last action into one of two piles is ultimately to waste your time, but to allow you to naturally communicate this in a prevalent case while making your code more concise seems to me a straightforward win. In truth, I've never confused dot syntax messaging with struct access. I think the reason my inner Mike Ash is showing is that, while I'm attracted to the concept of distinguishing between properties and behavior, I don't feel like I'm actually seeing the communicative benefit after these last few years of using dot syntax. The aesthetic of all messages expressed with the same syntax, as well as hiding the implementation detail of whether or not an ivar is backing a method, is appealing. Practically speaking, the fact that dot syntax is now conventional and that others will expect it means I probably won't stop using it. I simply may not be experienced enough to see the benefit that others do in using it.
|
|
#
?
Jan 8, 2013 22:38
|
|
|
Zhentar posted:Just to be clear, the trade-off here is install footprint vs. runtime performance. As for memory usage, the XCode way likely has lower peak memory consumption and equivalent steady state consumption. On that very note, I played with ImageOptim to do some batch reduction in size and it does work quite well. I did however notice that I still get much better results with Photoshop's Save for web and devices, and I'm not sure why. A 140kb 200x200 .png is only reduced to 130kb, whereas with PS I go all the way down to 43kb. I'm wondering if perhaps they're reach better for optimizing certain specific situations. Any thoughts?
|
|
#
?
Jan 9, 2013 08:03
|
|
|
ImageOptim is trying to figure out the ideal compression of the image you provide it. Save for web is altering the image you provide to be more compressible. The linked comparison uses ImageAlpha to similar effect.
|
|
#
?
Jan 9, 2013 17:03
|
|
|
Crap, computer crashed and I lost my post. Basically, I'm having a strange problem with In-App Purchase price formatting that I'd really like to fix. I'm grabbing the in-app purchase price from the App Store and using a NSNumberFormatter (NSNumberFormatterBehavior10_4, NSNumberFormatterCurrencyStyle) to format the price. [OK] User in Japan using Japanese with Japanese region sees ￥1000 [OK] User in Japan using English with Japanese region sees ￥1000 [WTF] User in Japan using English with American region sees $1000.00 Is there any way to get a region-appropriate converted price? So rather than $1000.00, it would show 1000 JPY in USD or whatever? I understand that it's a very fringe case, but... $1000.00 displaying is really, really irritating.
|
|
#
?
Jan 10, 2013 03:17
|
|
|
AFAIK, all NSNumberFormatter does is put the currency symbol and decimal/comma in the right spot. It doesn't do actual currency conversion for you (as the value of one currency vs another changes every day). Does StoreKit not provide a way to find out the price tier of an item? Or does it only send down a currency amount?
|
|
#
?
Jan 10, 2013 03:27
|
|
|
As far as I can tell, it only gives you a number through product.price... and that jives with my gut instinct, because otherwise you could easily just change your device settings and get a different price in a different region (if it just pulled from the tier). Edit: Hmm, though it does look like products have a priceLocale, so maybe I could force the formatter to use the appropriate locale rather than the device-specified one. Edit 2: Yep, that did the trick. [priceFormatter setLocale:product.priceLocale]; for anyone else who might be looking in the future. tarepanda fucked around with this message at 03:42 on Jan 10, 2013 |
|
#
?
Jan 10, 2013 03:30
|
|
|
We are noticing some pretty singificant Event loss using the Google Analytics for iOS 2.0b3. We have compared the event numbers we receive and they are roughly half of what they should be. We verified this by using our in house metrics and by comparison to the same app using Google Analytics for Android. A few other points: * We are using multiple trackers * We are using the default dispatching process * We are setting the dispatch interval to 60 seconds We've gone as far as capturing the network traffic to Google and it appears that our app is sending all the correct information info Google's analytics servers. I'm wondering if anyone else has moved onto this version of Google Analytics and noticed problems? Or if anyone has moved to 2.0b3 and not noticed any issues?
|
|
#
?
Jan 10, 2013 16:07
|
|
|
|
| # ? May 21, 2024 00:12 |
|
|
How do you guys manage multiple NSURLConnections in the same class? Do you key off something in the connection:DidReceiveData: delegate method and route the data to the appropriate property or what? I'm coding on flu meds so if this is really obvious I apologize 
|
|
#
?
Jan 10, 2013 17:58
|
|