A Chemist, Code & iOs

It is often the case that we need to persist a few bits of info or at least a single object, like a "user". Core data is too big for this, NSUserDefaults is sometimes not the best practice use case, and does not provide compiler auto-completion. The correct way is to create a (singleton) object for the data, and use NSKeyedArchiver for persistence, which is not super fast, but is straightforward and speed does not matter for small classes like this. It is not hard to use, but there are a few things that you have to do correctly. For a quick refresher, there are lots of examples, but this one is fine

provide a method to encode each property of the object by encodeForKey by giving it an NSString key that is the same name as the property.

Provide a method to decode each property the same way.

This leads to two problems:

Must manually match the @"keyName" to the @property name. The compiler does not help you here.

Must remember to add/modify the @"keyName" every time you add/modify a property name that you want to persist.

The most tedious (and treacherous) way:

[coder encodeObject:name forKey:@"name"]; [coder encodeObject:subgroups forKey:@"jobs"]; [coder encodeObject:tasks forKey:@"location"];

The less tedious way, using an array of keys and valueForKey:

- (NSArray *)keysForEncoding { return [NSArray arrayWithObjects:@"name", @"jobs", @"location", nil]; } - (void)encodeWithCoder:(NSCoder *)aCoder { for (NSString *key in self.keysArray) { [aCoder encodeObject:[self valueForKey:key] forKey:key]; } }

The worst thing is that both still have boilerplate which is not compiler checked.

So, thinking about this, I was trying to come up with a way to use introspection to eliminate the manual entry of a key array. This led me to a Objective-C runtime method that fit the bill.

+ (NSArray *)keysFromProperties { u_int count; objc_property_t* properties = class_copyPropertyList([self class], &count); NSMutableArray* propertyArray = [NSMutableArray arrayWithCapacity:count]; for (int i = 0; i < count ; i++) { [propertyArray addObject:@(property_getName(properties[i]))]; } free(properties); return [NSArray arrayWithArray:propertyArray]; }

So now my encoding does not depend on any array that I must manually fill, it is just a method and looks like this:

- (void)encodeWithCoder:(NSCoder *)aCoder { for (NSString *key in [[self class] keysFromProperties]) { [aCoder encodeObject:[self valueForKey:key] forKey:key]; } }

So I can simply add object and primitive data properties directly in the @interface, and the class takes care of the rest. I get autocompletion in the compiler, so there are no strings to keep track of.

Just a couple notes here, nothing earth shattering.

If you have a custom UITableViewCell with controls of some sort and you want to know in which cell a the value of a control changed, there are a few ways, one of which is bad, one of which is good.

bad:

UITableViewCell *cell = controlItem.superview;

This is dependent on the framework implementation at the time and in fact does not work for iOs 7 & 8. In those versions you would use:

controlItem.superview.superview

The fragility of this is obvious, especially if you're not thinking and implement it on a custom UITableViewCell that has a different hierarchy.

A typically better way to approach the problem is some form of this:

- (UITableViewCell *)cellForControl:(UIControl *)control { while (view != nil) { if ([view isKindOfClass:[UITableViewCell class]]) { return view; } view = view.superview; } return view; //will be nil }

Lately (along with the rest of the iOs/OsX community), have been trying to think more "functional"ly about my code, so I am trying to minimize reference to properties within functions or methods, I have been trying at least to think about using recursion whenever I see loops these days. This problem lends itself to an obvious recursion. I searched but I haven't seen this done around SO anywhere, though I did find this approach used in a slightly different (and cool1) context. Regardless, here is a recursive method to find the parent cell of a view:

- (UITableViewCell *)cellContainingView:(UIView *)view { if (view == self.view) { //this could also be a nil check return nil; } return ([view isKindOfClass:[UITableViewCell class]]) ? view : [self funcCellContainingView:view.superview]; }

I actually posted this version as a gist, which depends on finding no view, rather than self.view:

- (UITableViewCell *)cellContainingView:(UIView *)view { return (!view || [view isKindOfClass:[UITableViewCell class]]) ? (UITableViewCell *)view : [self cellContainingView:view.superview]; }

[viewTree]:

[Answer by chown](http://stackoverflow.com/questions/2343432/how-to-get-uiview-hierarchy-index-i-e-the-depth-in-between-the-other-subvi

(void)printViewHierarchy:(UIView *)viewNode depth:(NSUInteger)depth { for (UIView *v in viewNode.subviews) { NSLog(@"%@%@", [@"" stringByPaddingToLength:depth withString:@"|-" startingAtIndex:0], [v description]); if ([v.subviews count]) [self printViewHierarchy:v depth:(depth + 2)]; // + 2 to make the output look correct with the stringPadding } }

Topics of interest this week:

A few timely autolayout discussions

New implementation of ThoughtBot's map clustering algorithm

Mobile Processor Speeds

Marco Arment dispiritedly notes that processor speed is not increasing as quickly as they have historically, posting this plot of processor speed data:

<img alt="marcosPlot" src="http://www.marco.org/media/2014/09/iphone-geekbench-history.png" width=100%"> However, not to be all Asymco, knowing that he was just making a quick point, it is worth pointing out that the scale of absolute values obscures the growth in processor speeds.

If you instead plot the growth in single core and dual core processor benchmarks, the picture is a bit more complicated:

<img alt="mobile processor speed.png" src="https://draftin.com:443/images/21280?token=gBGHL0jtIANKmxIay7DK0D_-wOmO8oN9WTUTgt4v039LXHi9wi5ITl8zgxMXmYGuR30SkEO-eC0yo1tziln7uog" width=100%">

This view would also be improved by putting the Y-Axis on a log scale, but the point is still clear.1 In terms of single core improvements, only two of the last 5 processor transitions have been wildly larger than this year.

And in my ignorance, I am not clear if the GPU is included in the Multi-core number or not, and that seems to have had a bigger jump in performance than the CPU.

David Smith posted numbers for adoption rates of his app, sorted by phone type. He is curious about how quickly new screen sizes will be adopted (~30% in one year). 1

But of interest to me are what I consider to be the defining features of modern iOs devices: touch ID, and math coprocessors.

Roughly, based on his chart, we might expect that by the end of next year, ~60% of all iOs devices might be equipped with both.

That is sorta a big deal, for Pay and gaming.

Now that Xcode 6 is out of beta, if you want to continue running swift scripts on the command line in Mavericks, you must also install Xcode 6.1Beta. Then on the command line:

$ sudo xcode-select -switch /Applications/Xcode-Beta.app/Contents/Developer

Then to run the script:

xcrun swift scriptName.swift

If you want to run the REPL:

xcrun -sdk iphoneos swift

I modified the advice given by Rajan who has put together some great starter articles on Medium about learning Swift.

Now that auto layout is becoming the de facto for layouts, it is important to remember that you cannot simply animate the positions of views, layers and frames without having bizarre side effects. The constraints are still in effect and do not respond to the frame position changes.

I am not an expert, but this post by invasive code does a great job laying it out.

for most cases it boils down to something as simple as: 1. defining a constraint in Interface Builder 1. ctrl-dragging into the @interface section of your code to create a property. 1. animating the constraint.

The impetus of this post is that this is simple to do, but I always forget the specific wording of the code. So, today, I wrote a snippet for that.

self.<#constraintName#>.constant = <#constantValue#>;

[self.<#mainViewOrSubViewWithConstraint#> setNeedsUpdateConstraints];

[UIView animateWithDuration:2 animations:^{ [self.<#mainView#> layoutIfNeeded]; }];

Justin Williams is a great iOs developer and his podcast, Cocoa Radio, is a pretty great balance of info, technical detail and brevity for iOs development.

He is pre-releasing a book on Autolayout.

"Achieving Zen With Auto Layout" is the book I've always wanted to write. You can preorder and get beta access now. http://t.co/wLKfeeFOwp

— Justin Williams (@justin) July 15, 2014

So much (more to come from me) is happening with Auto-layout in interface builder that it is really time to understand how to do it correctly. So much coding time can be saved and so much is about to happen with regards to screen sizes that it will behoove all iOs (and OsX) devs to embrace auto layout fully.

This is probably super-unseemly, but why should that stop me?

Brent Simmons posted this

Here’s a line of code that just made the in-development app throw an exception:

NSArray *uniqueIDs = [syncNotes valueForKeyPath:​VSSyncNoteIDKey];

Looks good, right? But it’s wrong. I replaced it with this — and the bug was fixed: NSArray *uniqueIDs = [syncNotes valueForKeyPath:​@"uniqueID"]; I know the three knocks against using string literals:

It’s hard to spot typos by eye.

The compiler won’t catch errors.

If you make a change, you have to change it in multiple places.

But I’m exceptional at spotting typos. And I almost never have cause to change the value of a key. (And if I did, it’s not like it’s difficult. Project search works.)

This guy posted this

I’m not going to judge Brent here on his solution, but it seems to me like this problem would be much better solved by using string constants provided Xcode actually showed you the damn values of those constants in auto-complete.1

I responded with this in a tweet:

and Brent Simmons did this

my day is made...

This Blog g8productions looks really nice. Not a ton of posts, but they are simple, helpful, quick tips on things to use for effective iOs programming. I feel like I will just carve out an hour of time and just DO examples of each post.

I found it, because i was looking at an implemented iOs Tesseract library. That is pretty cool stuff!

This is not new ground, but another example of missing a couple key, helpful nuances. Now that I realize what I had NOT been doing, I now see a number of places that people have mentioned them

Reminder: Xcode lets you define your own snippets. Do This. Classic example of spending 1 minute to save yourself 1000 x (10-20 second + unnecessary mental effort). Take the 30 seconds required to:

Click on the snippets button on the right navigator.

Highlight the relevant code

Drag it into the code snippet area.

Modify the title, summary, completion shortcut and scope.

Don't forget to click "Done"

Reminder: You can define your own "placeholders" which you can navigate between. Simple define them by typing <#whatever description you want#>

Reminder: By defining a completion shortcut, you can have the snippet show up as you begin to type. I preface all of mine with cb, so that I can be sure that my universe of code completions will be prioritized.

Realization: Lots of somewhat seldomly used method declarations would be much better for me if I take the time to make them, instead of 1. struggle to remember 2. begin to type 3. realize I am forgetting something 4. Go hunt around for previous code or Google.

For example, unwindSegue declarations. I basically keep hunting around for previous declarations of these, because I keep wanting to make sure I get all the pieces correct.

Clarification: Code snippets let you define the scope in which the completion will be brought up to your keyboard. I hadn't really paid attention to this. But I had made a mistake with a recent code snippet's scope so it wasn't showing up. Of course, instead of solving this problem, I just avoided making new snippets, because it felt a little "broken". Fixed that error today. This is nice, because at least some snippets are really only going to be in one place versus the other.

Turns out that I had the scope wrong. Scope is something I had basically ignored. Turns out that was dumb. It's actually pretty handy. If I am trying to write an unwindSegue, I am definitely NOT going to want an NSLog to show up.

Question: It's not super important, but I would like the ability to have "tab-able" parentheses, square braces, curly or quotation marks, like those when you have auto-completed a method name using Xcode's built-in methods. Does anyone know how to do that. Well, I just asked an SO Question. Let's see if I get anything.

**Two Updates (July 18):

No answers to my question, though I have just added a <#;#> to the end of the code snippet so I can tab to that then delete or complete it as warranted

It is very common when debugging to want to view the various parameters of view frames. But since these are structs, there are no obvious % parameters in an NSLog statement to pass to get to the various components. It gets painful fast:

`NSLog(@"view frame x: %.0f y: %.0f", self.view.frame.origin.x, self.view.frame.origin.y);`

But it turns out that there are a great set of functions to turn these struct parameters into an NSString. I couldn't remember where and this Stack Overflow Post got me headed in the right direction:

NSLog(@"%@", NSStringFromCGRect(self.view.frame));

from the Documentation, the following are available.

NSStringFromCGAffineTransform NSStringFromCGPoint NSStringFromCGRect NSStringFromCGSize NSStringFromUIEdgeInsets NSStringFromUIOffset

Also, do not forget about the ever helpful:

NSLog(@"%s", __PRETTY_FUNCTION__);

This is very easy to do with storyboards with ONE key detail to remember1. But I struggled for a bit. Most of the examples that I saw did not highlight the key detail.

Basic idea of how it works:

The search bar controller has a separate tableview that it populates with the results of your search.

It populates its tableview with the same methods, though.

So you create a separate datasource that is filled with the results of your search, and fill the tableview accordingly.

But first, Here is the simplest way:

In your Storyboard, drag searchBar And Controller onto your tableview. You get all the delegate setup for free.

add <UISearch1. create an NSArray property to hold the objects from the search results.

you need to make four simple changes to your code

The first, and least obvious to me. in your cellForRowAtIndexPath method, you need to change UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier forIndexPath:indexPath]; to UITableViewCell *cell = [self.tableView dequeueReusableCellWithIdentifier:CellIdentifier forIndexPath:indexPath];

return the row count - (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section { return (tableView == self.searchDisplayController.searchResultsTableView)?self.searchObjects.count:self.objects.count; }

After dequeuing Cell as shown above, set the Cell's content with the correct data source. - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { ... cell.textLabel.text = (tableView == self.searchDisplayController.searchResultsTableView)?self.searchObjects[indexPath.row]:self.objects[indexPath.row]; return cell; }

Use the searchDisplayController delegate method to return the revised datasource according to whatever predicate you would like to use: -(BOOL)searchDisplayController:(UISearchDisplayController *)controller shouldReloadTableForSearchString:(NSString *)searchString { NSPredicate *resultPredicate = [NSPredicate predicateWithFormat:@"description contains[c] %@", searchString]; self.searchObjects = [[NSArray arrayWithArray:self.objects] filteredArrayUsingPredicate:resultPredicate]; return YES; } NOTE" "description" should be replaced with whatever property of the object that fills the array or datasource of your tableView. (another good reason to fill in the description property of your custom objects...

NOT NECESSARY, but nice is to add <UISearchBarDelegate, UISearchDisplayDelegate> to the interface declarations. It gives you method completion for free if you are using any of the delegate methods.

That's it. If using storyboards, then you don't even need to declare the searchDisplayControllerDelegate protocol up top as storyboard takes care of that for you.

Ugh!

So many little ways to go wrong with StoryBoards.

I had a UITableView nestled immediately beneath another UIView. No header, no section header, no insets. It should have looked like this: (terrible colors included to make sections clear)

But instead, it looked like this:

Now, I had a navigation item and it gets pushed by a navigation controller, so I new that it was somehow responding to that. But, wow, I couldn't find it for the life of me.

Then an SO post pointed me to the fact that it is not on the UITableView properties, but that I should be looking at the UiViewController Settings:

Mostly, I am excited, but I don't know when I am supposed to dive into:

4000 API changes

Extensions

Cloudkit

Swift