Why is the static keyword used in UITableViewCell identifiers?
I’ve read up on “static” on several occasions, including just before posting this question.
I’m still searching for an “Aha” though.
In the context of UITableView’s static comes up in Cell Identifiers in every piece of code I’ve looked at. For example in a recent CellForRowAtIndexPath:
static NSString *defaultIndentifier = @"Managed Object Cell Identifier";
My question is why do we need and use “static”?
- moveRowAtIndexPath - Moving cells between sections
- Can you add archive file directly to XCode Organizer?
- App not setup: This app is still in development mode
- Best way to use iCloud Documents Storage
- Realm Swift: how to catch RLMException?
- Cannot call value of non-function type 'Any?!' :- Firebase,Swift3
3 Solutions Collect From Internet About “Why is the static keyword used in UITableViewCell identifiers?”
So that it will only be constructed once. If it’s not static, you’ll be making one every time the message is sent (which is a lot)
There’s no real benefit here. It’s mostly just a hint to the reader that the same value is used for all cells in this particular bit of code. As the identifier itself is a constant string, it gets compiled into an immutable chunk of memory and referenced as the same pointer every time, e.g. there is no cost involved in constructing the string even if you remove the
My guess is that by declaring the string as static, that every time it gets passed into
-dequeueReusableCellWithIdentifier:CellIdentifierforIndexPath: that the same pointer is used each time (as statically declared variables are allocated only once on the heap, very early in a program’s execution)
[NSString -isEqualToString:] is most likely implemented to perform a pointer compare first, followed by a character-wise compare as the fallback, which I supposed could shave off a few cycles on each iteration.
There’s not much to gain from this, as (a) table cell re-population operates on a typically very small set of cells, and is well optimized, and (b) table refresh is bursty — it happens once and then doesn’t happen again until the user scrolls or application logic changes up the content — if you end up calling
-reloadTable 100 times a second, then there’s clearly something wrong with your application logic.
I suspect the static keyword is a vestigial legacy convention — maybe back in the day, Apple hashed on the pointer, rather than performing a proper string compare.
- provide simple method to get current speed (implementing speedometer)
- iOS in-app purchase auto-renewable subscriptions free trial option not available?
- Optimizing this Core Data request
- Split large Array in Array of two elements
- UITableView scrollToRowAtIndexPath not working for last 4
- Sprite Kit physicsBody.resting behavior
- Is it possible to change a UIButtons background color?
- Why are emoji characters like 👩👩👧👦 treated so strangely in Swift strings?
- How to fetch images from photo library within range of two dates in iOS?
- iOS – CoreLocation and geofencing while app is closed
- NSDate returns wrong date on the first of month
- Type 'AnyObject' does not conform to protocol 'SequenceType'
- How To Get Directory Size With Swift On OS X
- How to lock screen in portrait/landscape in iPhone?
- Swift: dictionary access via index