Re: iCloud CloudKit in Swift. How do I code perRecordProgressBlock?
Re: iCloud CloudKit in Swift. How do I code perRecordProgressBlock?
- Subject: Re: iCloud CloudKit in Swift. How do I code perRecordProgressBlock?
- From: Alex Zavatone <email@hidden>
- Date: Wed, 04 Mar 2015 15:02:15 -0500
FWIW, I find that using "my" as a prefix is handy to specify a local, as it is a brief visual notification that the variable is a local just by eyeballing it. Sometimes it adds greater clarity.
Just my 2 cents,
Cheers.
Sent from my iPad. Please pardon typos.
On Mar 4, 2015, at 2:48 PM, Fritz Anderson <email@hidden> wrote:
> On 2 Mar 2015, at 1:21 PM, Mutlu Qwerty <email@hidden> wrote:
>
>> Here is what I have tried, what is the correct way to code this block?
>>
>> var counter: Int = 0
>> let myRecID: NSString = "00722371-b24d-421f-99c6-63d06226253e"
>> var myCKRecordID: CKRecordID! = CKRecordID(recordName: myRecID)
>> let myCKRecordIDArray: [CKRecordID!] = [myCKRecordID]
>> var myCKFetchRecordsOperation: CKFetchRecordsOperation = CKFetchRecordsOperation(recordIDs: myCKRecordIDArray)
>>
>> var myProgress: Double = 0.0
>> myCKFetchRecordsOperation.perRecordProgressBlock( { (myCKRecordID, myProgress) -> Void in
>> print("At perRecordProgressBlock ")
>> print(counter++)
>> print(" ")
>> println(myProgress)
>> })//end of block
>>
>
> I don’t have an active CloudKit entitlement, so I can’t test this, but I have some observations.
>
> First and most important:
>
> In what way does what you are doing prove to be incorrect? Fails to compile, runtime error, no error but unexpected results, block never entered?
>
> --
>
> Passing observations:
>
> Most of the type declarations for your vars and lets are unnecessary. Swift will do better than you can (barring bugs in the compiler) at using the values you assign to the symbols to infer the types. That may force you to do coercions later, but having to do explicit coercions at the places they are needed shows the reader — and you — something about the design and effect of your code.
>
> --
>
> It appears you expect the closure parameters myCKRecordID and myProgress to be the same as the vars of those names in the func that contains the call to perRecordProgressBlock. They aren’t. They’re parameter names that you’ve made identical to those of vars you use elsewhere.
>
> If you had a func that had vars a and b, and it called an outside func that has the signature
>
> func aFunc(a: String, b: Int)
>
> you would not expect aFunc’s a and b parameters to be the same variables as the a and b in the function that called it. Same thing.
>
> Given that the perRecordProgressBlock closure is within the scope of the block that declares counter, and the closure doesn’t redefine the symbol, you have counter right.
>
> --
>
> If it were me, I’d write the perRecordProgressBlock call thus:
>
> myCKFetchRecordsOperation.perRecordProgressBlock {
> _, cloudKit_sProgress in
> println("At perRecordProgressBlock \(counter++) \(cloudKit_sProgress)")
> }
>
> In other words, let the language do your work for you, don’t bother to name things you won’t use (in your real code, I assume you’d have to replace _ with cloudKit_sRecordID), and don’t confuse the reader by giving the same name to two different objects.
>
> --
>
> I assume you don’t use the “my” prefix as liberally as this in your real code. The reader sees that the symbols are defined right there. She can do the math about their being yours. It’s distracting.
>
> --
>
> These things may or may not solve your problem — you haven’t really said what your problem is.
>
> — F
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden