|
fankey posted:Apparently I kicked the write-only property hornets nest. I was mainly curious as to why it didn't work. Is it an intentional design choice in ObjC to fail so one cannot create write-only properties or is it a side effect of how properties are implemented? Objective-C explicitly calls out no write-only properties, as I stated in my earlier post.
|
#
?
May 27, 2011 07:42
|
|
|
|
| # ? May 15, 2024 03:12 |
|
|
fankey posted:Apparently I kicked the write-only property hornets nest. For what it's worth, I don't think there's any problem with the idea of a write-only property. It just seemed like a bad fit for what you described.
|
|
#
?
May 27, 2011 08:27
|
|
|
Carthag posted:foo.bar = @"whatever"; //not foo.Bar = ... In any case, you can do it with one of the following: code:code:
|
|
#
?
May 27, 2011 08:34
|
|
|
Small White Dragon posted:You can create a write-only property (and it will work), if you provide the implementation, although as noted elsewhere it's probably bad form. Again, this is just faking it by not responding to the dynamic getter invocation or by directly throwing "doesNotRecognizeSelector" from the getter implementation. The IDE won't identify an attempt to get that property as invalid because the compiler believes you are adhering to the spec by providing a getter at runtime (due to @dynamic). You are far better off avoiding these sorts of tricks and just adding setXYZ methods (without trying to use property syntax) or by providing actual getters. At least in my opinion, attempts to be "clever" in code tend to backfire because later on you forget the clever stuff you did or if someone else needs to maintain it they can't follow it, etc. This is free advice though so I guess it's worth what you pay for it.
|
|
#
?
May 27, 2011 16:35
|
|
|
I'm looking for a way to disable the snapshot that displays when resuming from a background state. I understand that the image is automatically created between when the home button is pressed and when the app enters the background. (Would it be possible to somehow force the thing to take a screenshot of a solid black screen?) Just to make sure we're clear, I'm not talking about Default.png - I'm talking about the image that's displayed for a fraction of a second when an in-memory app window is expanding from the center of the home screen, just after you've tapped the icon. This is a pretty vague question, but I appreciate any and all help. edit: I'm thinking that adding UIApplicationExitsOnSuspend to my info.plist to just disable multitasking might be the easiest way. That could work, I guess. edit2: Looks like the snapshot is taken right after applicationDidEnterBackground returns. So I guess that solves that. Sorry! Major Thom fucked around with this message at 01:18 on May 28, 2011 |
|
#
?
May 28, 2011 01:07
|
|
|
Argh, somebody please explain countByEnumeratingObjectsWithState: to me. From reading the docs, and googling around, I can't see that we have any way to call cleanup code. There's a stackbuf, and a state, but nothing I've been able to find says that if I put objects in stackbuf or state->state or state->extra that there's any way to make sure dealloc gets called. Am I missing something, or is that just a constraint I need to deal with?
|
|
#
?
May 28, 2011 03:28
|
|
|
It's just a constraint you need to deal with. You will not get any callbacks when the loop is complete, or if it's aborted part-way either normally or abnormally.
|
|
#
?
May 28, 2011 03:33
|
|
|
rjmccall posted:It's just a constraint you need to deal with. You will not get any callbacks when the loop is complete, or if it's aborted part-way either normally or abnormally. Crap. So, the implementation at line 354 is going to leak the NSEnumerator (and self, since enumerators retain the objects they enumerate) that's stored in state->state? e: derp, forgot to link what I was talking about : Here it is
|
|
#
?
May 28, 2011 04:09
|
|
|
No, because the default convention for methods is to return at +0, i.e. autoreleased or otherwise held.
|
|
#
?
May 28, 2011 04:58
|
|
|
rjmccall posted:No, because the default convention for methods is to return at +0, i.e. autoreleased or otherwise held. poo poo, it looks like there's a core part of memory management I'm not aware of. I understand that newXXX and init are retain count +1, and that other methods are usually +0, but I thought that an object with a retain count of 0, in non-gc mode, is immediately deallocated, so unless you were returning a reference to an elsewhere-retained object, you always need to take ownership for the caller like new and init do. I also thought (or still think) that objectEnumerator returns a new NSEnumerator*, which would have a retain count of 1 so it doesn't immediately dalloc, that you would have to clean up when you're done. Is retain 0 something where it deallocs when it leaves scope? Because that would rule in about a thousand ways.
|
|
#
?
May 28, 2011 05:13
|
|
|
You need to read the Cocoa Memory Management Programming Guide.
|
|
#
?
May 28, 2011 06:16
|
|
|
Read it, got it, thanks.
|
|
#
?
May 28, 2011 20:52
|
|
|
Has anyone had positive experiences working with multi-target mobile development platforms? (ex. Airplay and others)
|
|
#
?
May 30, 2011 01:11
|
|
|
Vanan posted:Has anyone had positive experiences working with multi-target mobile development platforms? (ex. Airplay and others) Well I am a C# dev by day, so I've used mono-touch which is pretty cool and I looked at other toolkits but part of the process for me was wanting to learn the native toolset so I just bit the bullet and learned Objective-C. Maybe some others here can speak more to developing for multiple mobile platforms at once but so far everything I've heard says iOS is where the money is. As far as games go, the Unreal SDK is now free up to 50,000 in revenue and supports all the major mobile platforms IIRC so there's that.
|
|
#
?
Jun 1, 2011 17:27
|
|
|
Double checking something I am 99.999998% positive of: I have a client who I am building an app for, who does not won a computer, only an iPad. When I generate an Ad Hoc build .ipa file, there is no way to install this on a device w/o using a computer and iTunes, right? (I know it's possible w/ jailbreaking and whatnot, but his device isn't jailbroken, nor do I wish to go down that path.) Given that without a machine of his own, he'd have to hook his iPad up to a friend's computer, which would then sync his device to that machine upon installing the app, which is also not desirable, so the best solution is probably for him to buy a cheap-rear end netbook or something?
|
|
#
?
Jun 1, 2011 19:57
|
|
|
Saw an app to seems to run in the background, intercepting text messages and auto-replying to the original senders. How in the hell is that possible? http://www.makeuseof.com/dir/dont-text-me-auto-reply-text-messages/
|
|
#
?
Jun 1, 2011 20:22
|
|
|
Lumpy posted:Double checking something I am 99.999998% positive of: I have a client who I am building an app for, who does not won a computer, only an iPad. When I generate an Ad Hoc build .ipa file, there is no way to install this on a device w/o using a computer and iTunes, right? (I know it's possible w/ jailbreaking and whatnot, but his device isn't jailbroken, nor do I wish to go down that path.) You can distribute your adhoc builds from a website. I have my clients visit a page on their device and it installs it no problem, no syncing, no iTunes. I use https://github.com/TheRealKerni/HockeyKit - just the server-side stuff though, I haven't messed with the client-side autoupdating functionality.
|
|
#
?
Jun 1, 2011 20:52
|
|
|
Lumpy posted:Double checking something I am 99.999998% positive of: I have a client who I am building an app for, who does not won a computer, only an iPad. When I generate an Ad Hoc build .ipa file, there is no way to install this on a device w/o using a computer and iTunes, right? (I know it's possible w/ jailbreaking and whatnot, but his device isn't jailbroken, nor do I wish to go down that path.) You could also use Testflight ( http://www.testflightapp.com ) , if you don't want to go through all of the server rigamarole bullshit. I'm pretty (100%) sure it's what the nimblebit guys use, and we all know what colossal jerks they are.
|
|
#
?
Jun 1, 2011 21:23
|
|
|
Inevitable Ross posted:You could also use Testflight ( http://www.testflightapp.com ) , if you don't want to go through all of the server rigamarole bullshit. I'm pretty (100%) sure it's what the nimblebit guys use, and we all know what colossal jerks they are. Yeah Testflight is free and awesome, and gives us more time to learn new ways to be colossal jerks.
|
|
#
?
Jun 1, 2011 22:07
|
|
|
wellwhoopdedooo posted:poo poo, it looks like there's a core part of memory management I'm not aware of. I understand that newXXX and init are retain count +1, and that other methods are usually +0, but I thought that an object with a retain count of 0, in non-gc mode, is immediately deallocated, so unless you were returning a reference to an elsewhere-retained object, you always need to take ownership for the caller like new and init do. For the record, don't think about retain counts or consider them at all in your code. Simply follow object ownership rules, which state that new/alloc/copy/mutableCopy return objects that you own, and convenience constructors return objects you don't own. Retain count is an implementation detail that may behave differently than you expect (for example, retainCount is never actually set to 0 when an object is deallocated). Don't bother reading retainCount for memory debugging purposes, because the value will be unpredictable. You never know what system framework might retain your object for some internal purpose. wellwhoopdedooo posted:[tell] me about Core Data. Core Data manages your data's object graph including relationships, data constraints, faulting, and persistence. It also automatically handles undo/redo for you. It may seem a little complicated sometimes, but the advantages become clearer in the long-term unless your data is very simple and could be stored in something like a property list. Apple is investing a lot of work into Core Data, and standardizing your applications on it will bring you additional features with each new release of the framework, some of which are unfortunately under NDA at this time.
|
|
#
?
Jun 1, 2011 22:29
|
|
|
OHIO posted:Good stuff Inevitable Ross posted:More good stuff Thank you guys for the info. I think I'll use the one that has the colossal jerk seal of approval.
|
|
#
?
Jun 2, 2011 00:06
|
|
|
Toady posted:Simply follow object ownership rules, which state that new/alloc/copy/mutableCopy return objects that you own This isn't quite what the memory management rules say about new/alloc/copy/mutableCopy. The rule, as of this post, is: ADC posted:You take ownership of an object if you create it using a method whose name begins with “alloc”, “new”, “copy”, or “mutableCopy” (for example, alloc, newObject, or mutableCopy), or if you send it a retain message. (Emphasis mine.) The alloc/new/copy/mutableCopy bit used to be a little different, where the word "copy" anywhere in the method name signified a +1 ownership reference, but that is no longer the case. It's important to keep this in mind, because the clang static analyzer definitely does.  quote:and convenience constructors return objects you don't own. This is definitely a misrepresentation of the rules. Being a convenience method, regardless of whether it is responsible for the construction of an object, is not relevant to whether or not it returns an object with a positive ownership reference. Just follow the contract. edit: added link edit: removed redundant -retainCount advice Mikey-San fucked around with this message at 01:22 on Jun 2, 2011 |
|
#
?
Jun 2, 2011 01:11
|
|
|
Mikey-San posted:This isn't quite what the memory management rules say about new/alloc/copy/mutableCopy. The rule, as of this post, is: wellwhoopdedooo wrote newXXX, so I didn't write "begins with" because he already knew that. "new/alloc/copy/mutableCopy" was just an example I used in making a point about ownership over retain counts. I wasn't trying to summarize the entirety of the rules, which were already linked. quote:This is definitely a misrepresentation of the rules. Being a convenience method, regardless of whether it is responsible for the construction of an object, is not relevant to whether or not it returns an object with a positive ownership reference. I intentionally used the term convenience constructor because they have a specific role in Apple's memory management documentation: "Many classes provide methods of the form +className... that you can use to obtain a new instance of the class. Often referred to as 'convenience constructors', these methods create a new instance of the class, initialize it, and return it for you to use. You do not own objects returned from convenience constructors, or from other accessor methods." (emphasis not mine) P.S. God can -release all the kittens he wants. Toady fucked around with this message at 02:47 on Jun 2, 2011 |
|
#
?
Jun 2, 2011 02:26
|
|
|
Ultimately, that just means the convience constructors you see provided by Apple's frameworks (e.g., stuff like +[NSArray arrayWith*:]) are following the fundamental rule, and don't start with the four horsemen (new/alloc/copy/mutableCopy). Otherwise, they wouldn't be very convenient! That doesn't make them special, per se, it just makes them well-named.  edit: To be clear, I'm speaking strictly in terms of what you (in the royal sense, of course) should be most concerned with. I don't think I can come up with a single convenience constructor in Foundation, for example, that returns an object with a positive ownership reference. Those also follow the fundamental rule(s), so if you stick to that, you're golden. No need to consider whether it's a convenience method or not. quote:P.S. God can -release all the kittens he wants. Just something that had been on my mind. Not a reply to you in particular! Mikey-San fucked around with this message at 03:04 on Jun 2, 2011 |
|
#
?
Jun 2, 2011 02:46
|
|
|
Mikey-San posted:Ultimately, that just means the convience constructors you see provided by Apple's frameworks (e.g., stuff like +[NSArray arrayWith*:]) are following the fundamental rule, and don't contain the four horsemen (new/alloc/copy/mutableCopy). Otherwise, they wouldn't be very convenient! That doesn't make them special, per se, it just makes them well-named. Well, that doesn't contradict what I wrote, as I was just restating Apple's docs. That said, I'm not aware of a definition of convenience constructor that doesn't refer to className... methods that perform their own alloc and register the instance in an autorelease pool. According to Apple's description anyway, if a method name began with one of the four horsemen, it wouldn't be a convenience constructor.quote:To be clear, I'm speaking strictly in terms of what you (in the royal sense, of course) should be most concerned with. I don't think I can come up with a single convenience constructor in Foundation, for example, that returns an object with a positive ownership reference. Those also follow the fundamental rule(s), so if you stick to that, you're golden. No need to consider whether it's a convenience method or not. You're right; however, sometimes it's helpful to explain why convenience constructors differ from other creation methods that return objects, because convenience constructors confuse people, and citing the ownership rules isn't enough for them to understand. In my opinion, it's not a violation of black box ownership rules to be aware of the reasons for certain behaviors; especially since, for example, you must create your own autorelease pool for a thread or Foundation tool, or else Cocoa convenience constructors will leak. There is some necessary transparency in Cocoa's memory management implementation, and Apple publicly documents all of this. When it comes down to how to actually treat the objects in your code, though--as you said, follow the rules. quote:Just something that had been on my mind. Not a reply to you in particular! It was a good line! Put it on a t-shirt in time for WWDC. Toady fucked around with this message at 04:28 on Jun 2, 2011 |
|
#
?
Jun 2, 2011 04:21
|
|
|
I'm sure you guys get this question all the time, but I couldn't find an answer with search, so here goes. What's the difference between an ivar and a @property? I get that one has setter and getter methods when you @synthesize it, but is that it?
|
|
#
?
Jun 2, 2011 17:46
|
|
|
stray posted:I'm sure you guys get this question all the time, but I couldn't find an answer with search, so here goes. What's the difference between an ivar and a @property? I get that one has setter and getter methods when you @synthesize it, but is that it? There are practical consequences of that — for example, you can use key-value observing to get notified of changes to a property precisely because there are methods to hook — but at a high level, yes, that's it: a synthesized property is just a couple of methods wrapping an ivar, which (by default) has the same name as the property.
|
|
#
?
Jun 2, 2011 18:13
|
|
|
Toady posted:It was a good line! Put it on a t-shirt in time for WWDC. If only I had the time! So, you're all going, riiiight?
|
|
#
?
Jun 2, 2011 20:25
|
|
|
Mikey-San posted:If only I had the time!
|
|
#
?
Jun 2, 2011 20:45
|
|
|
Anyone have suggestions for how to track down properties that are retained, but not released in dealloc?
|
|
#
?
Jun 2, 2011 22:07
|
|
|
My (company's) app was approved in just under a week. It's such a great feeling to finally have an app on the app store. How long does it usually take for stuff to show up in the app store search? vvv You speak the truth. It appeared and disappeared for a while, but seems to be there for good now. vvv aehiilrs fucked around with this message at 04:49 on Jun 3, 2011 |
|
#
?
Jun 2, 2011 23:56
|
|
|
aehiilrs posted:My (company's) app was approved in just under a week. It's such a great feeling to finally have an app on the app store. A couple of hours at most (in my experience). Does anyone know of a framework that handles options, whether via NSUserDefaults or via CoreData? Duplicating the Settings app (both on iPad and iPhone) seems to be boilerplate that tons of apps need to re-invent. If there isn't one I was thinking of trying to create one that drives off a specific CoreData schema and understands various data types, eg: within each Category there are either other categories or option items. Ones marked boolean use a switch accessory view, others might have a list of allowed values or an allowed numeric range, etc. Ones marked with a custom flag would raise an event to the delegate to have the app provide a custom picker for that option item. Elsewhere in the app you could just ask for the current value for any given key and get it. Would there be any interest here in contributing code to that sort of project?
|
|
#
?
Jun 3, 2011 04:36
|
|
|
rjmccall posted:There are practical consequences of that — for example, you can use key-value observing to get notified of changes to a property precisely because there are methods to hook — but at a high level, yes, that's it: a synthesized property is just a couple of methods wrapping an ivar, which (by default) has the same name as the property. Note that the existence of a @property declaration for a class doesn't mean the property has been declared to be key-value observable, because the class might not use accessors internally. The fact that synthesized methods follow KVC accessor naming conventions is incidental.
|
|
#
?
Jun 4, 2011 00:03
|
|
|
Toady posted:Note that the existence of a @property declaration for a class doesn't mean the property has been declared to be key-value observable, because the class might not use accessors internally. The fact that synthesized methods follow KVC accessor naming conventions is incidental. I'd argue a class whose instances don't (appear to) use its own accessors is a bug that should be fixed, but it's certainly fair to point this out about Apple's frameworks: it's not KVO unless the docs say so. (And this point is explicitly made in the KVO programming guide.)
|
|
#
?
Jun 4, 2011 08:24
|
|
|
Anyone have ideas (or even have this problem) on preventing peoples fingers from getting 'lost' on the touch screen in games? A lot of games set the iPhone up like a video game controller, arrows on the left bottom corner and buttons on the right. But what happens to me is that since I'm not touching an actual button, my thumb will wander from say 'left' to 'right' or from 'jump' to 'shoot'. Or off the touch screen area entirely. Very frustrating.
|
|
#
?
Jun 4, 2011 14:39
|
|
|
Bob Morales posted:Anyone have ideas (or even have this problem) on preventing peoples fingers from getting 'lost' on the touch screen in games? I'm not sure what you're asking, but maybe you could set the actions for the buttons from 'touch up inside' to 'touch down inside'?
|
|
#
?
Jun 4, 2011 19:56
|
|
|
Bob Morales posted:Anyone have ideas (or even have this problem) on preventing peoples fingers from getting 'lost' on the touch screen in games? I agree, but ideally you could design the game around a touch interface and not put in a fake game controller.
|
|
#
?
Jun 4, 2011 20:40
|
|
|
Hi all, I just received an iPad as a gift and I'm having fun with it, but getting frustrated by a few things as well. I know this is an app development thread, but I'm hoping you can point me in the right direction. I'm a software developer by trade so I'm confident that I can learn what's required as long as it's possible. But I'm getting the feeling that that's not the case. Is app development the only kind of development that I can do for the iOS? I know that apps are all that you can create to sell to others, but (if I can get the correct development environment set up) can I alter iOS functionality itself on my own iPad purely for my own use? Even if my solutions are just hacks, is there any pathway for getting into this, or would I have to reverse-engineer the firmware to do even the simplest things? The main thing I want to do is allow myself to use the dvorak keyboard layout. It seems to support it via hardware keyboards, but not on-screen. I don't even need to change how the keyboard looks, I just need some way of convincing iOS that 'S' is mapped to 'O', etc. Do I have a hope in hell?
|
|
#
?
Jun 6, 2011 07:53
|
|
|
deep square leg posted:Do I have a hope in hell? First, you can create apps solely for your own use. When you do that, of course, they don't have to pass Apple validation, so you're free to screw around with the stuff that's normally off limits. Second, you might want to consider jailbreaking. If you go this route, you can install sshd on the iPad, ssh to it, su(do) to root, and modify the OS's default configuration and files.
|
|
#
?
Jun 6, 2011 08:34
|
|
|
|
| # ? May 15, 2024 03:12 |
|
|
Thanks, good to know - I just wanted to be sure it wasn't a flat-out "no". For the first part, I had believed that even personal apps could still only use whatever functionality was available in the API, and I wasn't sure if the kind of thing I want to change would be available. I'll do some research. For the second, I assumed I'd be waiting until an iPad 2 jailbreak became available, but my concern was still that everything on the filesystem would still be compiled in such a way to make alteration difficult. Again, I'll look into it.
|
|
#
?
Jun 6, 2011 09:19
|
|