Sandmoose @sandmoose - Tumblr Blog

Using Charles with a 4th Generation Apple TV

Proxying network traffic through Charles is a common practice with iOS developers which helps us examine our application's API requests and responses. Since tvOS doesn't have a UI for setting an HTTP proxy, how is this done with an Apple TV? Answer: Custom Profile.

First download Apple Configurator 2 from the Mac App Store. This is how you'll add/remove profiles for your Apple TV.

Open Apple Configurator 2 and select File | New Profile (⌘N).

In the Global HTTP Proxy section add the IP address you want to proxy through.

Save the profile. It should have a .mobileconfig extension.

From the main Configurator screen, assuming you have your Apple TV connected via USB, right click on your Apple TV and select Add | Profiles... from the context menu. Select the .mobileconfig file you created in the previous step and click Add.

It should take a few moments to copy the profile to your device. Now run your app, approve the connection from Charles if needed, and watch the network traffic flow through Charles.

Except for SSL traffic. Here's how to get SSL proxying working too. This assumes you already have a Charles root certificate on your workstation. If not, see SSL Certificates on the Charles Proxy website.

Open Keychain Access, find your Charles Proxy Custom Root Certificate and make sure it's selected. Choose File | Export Items... and save the .cer file somewhere.

Switch back to Apple Configurator 2 and open the profile you had created previously. In the Certificates section click the Configure button and select the .cer file you exported in the previous step. Save the profile.

From the main screen of Apple Configurator 2, select your device and add the profile. Be sure to remove it first if needed. SSL traffic should proxy the same as everything else now.

Simple Brew Cheat Sheet

Here's a simple cheat sheet for regular people whose lives don't revolve around Brew, but want to use Brew every once in a while to install and update software.

Install Xcode Command Line Tools

xcode-select --install

Find out what's wrong with your installation

brew doctor

Update brew. Should be run once every 24 hours

brew update

Upgrade all packages

brew upgrade

List all packages

brew list [--versions]

List all outdated packages

brew outdated

Upgrade specific package

brew upgrade [package]

If you have a 4th generation Apple TV (the one with the Siri remote) then go to the App Store and search for 'adlib'.

#appletv #app

We Are More Powerful Than We Think

We are more powerful than we think. Seriously. We are *more powerful* than *we think* we are! This doesn't mean that we have a reserve of unrealized talent we're not aware of. This means that the talent and abilities we already possess are sufficient for greatness. What's holding us back is our belief and confidence in those talents. What's keeping us down is our assumption that we're too small to make a difference. Greatness doesn't necessarily mean affecting millions of people. It doesn't necessarily mean playing on the world stage. It doesn't even have to mean being recognized by our peers as being great. It means showing up everyday and doing our best work. It means making a positive difference in the lives of the people you come into contact with on a daily basis. If you can bring joy and positivity to one person and make a real impact on them you have achieved greatness. There's nothing wrong with visionaries who change the world with new technologies. Or scientists who make discoveries that change how we view the world. Or leaders who can organize and motivate large numbers of people. These kinds of people are necessary to move civilization forward. But even better is the greatness of ordinary people living ordinary lives trying to make their own small part of the world a better place. If enough people really believed in their ability to make a difference in the lives of the people around them, we'll see real change in the world at large.

Swift and Globals

We're all aware that global variables are bad and that we shouldn't do globals. Mmmkay? But! ...sometimes you need globally available information like user interface idiom or OS version. This information is available from UIDevice and you can grab it from anywhere in your app.

Testing Device Idiom and OS Version in Swift

if UIDevice.currentDevice().userInterfaceIdiom == UIUserInterfaceIdiom.Phone { ... } if UIDevice.currentDevice().systemVersion.compare("8.0", options: NSStringCompareOptions.NumericSearch) != NSComparisonResult.OrderedAscending { ... }

However, that's a lot type type and isn't easy to read either. In Objective-C we could use macros in the pre-compiled header to make application code easier to read and write.

ProjectName-Prefix.pch

#define isPhone ([[UIDevice currentDevice] userInterfaceIdiom] == UIUserInterfaceIdiomPhone) #define isIOS8 ([[[UIDevice currentDevice] systemVersion] floatValue] >= 8.0)

Application Objective-C Code

if isPhone { ... } if isIOS8 { ... }

But Swift doesn't have macros. Swift does, however, have a global namespace. Anything in that global namespace can be access by any other file in the same module. So you can do something like this.

Globals.swift

let isPhone = UIDevice.currentDevice().userInterfaceIdiom == UIUserInterfaceIdiom.Phone let isIOS8 = UIDevice.currentDevice().systemVersion.compare("8.0", options: NSStringCompareOptions.NumericSearch) != NSComparisonResult.OrderedAscending

Application Swift Code

if isPhone { ... } if isIOS8 { ... }

That's much better. Using the global namespace to define easy to type and read constants for system provided information feels acceptable to me. Just remember not to abuse it you should be okay.

#swift #objective-c

Forcing Landscape Orientation in Swift

Problem: You want a view controller to always display in landscape orientation. Left or right doesn't matter. Ideally, the user should be able to flip their device around to either side. As long as things are always in landscape all is good. Chances are you're looking for the UIInterfaceOrientationMask enum and not the more limited UIInterfaceOrientation.

override func supportedInterfaceOrientations() -> Int { return Int(UIInterfaceOrientationMask.Landscape.rawValue) }

#iOS Development #Swift

Caching NSDateFormatter

Instantiating NSDateFormatter objects is slow. Most well-written apps that use NSDateFormatter will make efforts to reduce the number unique instances created. Using a static property is sufficient for most cases, but what if you work on a large app where lots of NSDateFormatter objects are needed by a large number of classes. Wouldn't it be nice if there was an NSCachedDateFormatter that keeps track of what it has instantiated and will return cached objects and only instantiate new ones when necessary? Wouldn't it be nice if NSCachedDateFormatter was a singleton and could be used app-wide? I wrote this class as an attempt to fulfill this need.

class CachedDateFormatter { static let sharedInstance = CachedDateFormatter() var cachedDateFormatters = [String: NSDateFormatter]() func formatterWith(#format: String, timeZone: NSTimeZone = NSTimeZone.localTimeZone(), locale: NSLocale = NSLocale(localeIdentifier: "en_US")) -> NSDateFormatter { let key = "\(format.hashValue)\(timeZone.hashValue)\(locale.hashValue)" if let cachedDateFormatter = cachedDateFormatters[key] { return cachedDateFormatter } else { let newDateFormatter = NSDateFormatter() newDateFormatter.dateFormat = format newDateFormatter.timeZone = timeZone newDateFormatter.locale = locale cachedDateFormatters[key] = newDateFormatter return newDateFormatter } } }

Use the CachedDateFormatter singleton to instantiate any NSDateFormatter object you need. The formatterWith function returns a NSDateFormatter object and stores it in a dictionary based on format string, time zone and locale for future use. If another part of the app needs a date formatter with those same values it'll get the cached version.

Usage from Swift

let dateFormatter = CachedDateFormatter.sharedInstance.formatterWith(format: "yyyy-MM-dd'-'HHmm", timeZone: NSTimeZone.localTimeZone(), locale: NSLocale(localeIdentifier: "en_US"))

Since Swift allows for default argument values you can omit the second and/or third argument. A minimum call that defaults to the local time zone and "en-US" locale would look like...

let dateFormatter = CachedDateFormatter.sharedInstance.formatterWith(format: "yyyy-MM-dd'-'HHmm")

Usage from Objective-C

Objective-C doesn't support the concept of optional arguments so it must always be called with all three arguments in Objective-C.

NSDateFormatter *dateFormatter = [[CachedDateFormatter sharedInstance] formatterWithFormat:@"yyyy-MM-dd'-'HHmm" timeZone:[NSTimeZone defaultTimeZone] locale:[NSLocale localeWithLocaleIdentifier:@"en-US"]];

It may be overkill for smaller apps but could come in handy for larger code bases. Any issues or suggestions for improvement can be made on the Gist for CachedDateFormatter.

#swift #objective-c #iOS Development

How to Zoom a Window in Yosemite

I'm a little late to the party on this. Ever since I installed Yosemite I've been using pressing ALT to make the green full-screen window button go into "zoom" mode instead. Turns out you can just double-click/tap an empty area of the title bar to trigger the zoom behavior. Much easier.

#yosemite #fullscreen #zoom

Adding an image to a UILabel

Sometimes it's nice to be able to insert an image into a UILabel. Initially, I was prepared to deal with container views, subviews, and autolayout, but it turns out to be much easier than that in iOS 7+ with NSTextAttachment.

NSTextAttachment *attachment = [[NSTextAttachment alloc] init]; attachment.image = [UIImage imageNamed:@"favorite"]; NSAttributedString *attachmentString = [NSAttributedString attributedStringWithAttachment:attachment]; NSAttributedString *title = [[NSAttributedString alloc] initWithString:[NSString stringWithFormat:@" %@", @"Ready Player One"]]; NSMutableAttributedString *attributedTitle = attachmentString.mutableCopy; [attributedTitle appendAttributedString:title]; label.attributedText = attributedTitle;

#objective-c #iOS Development

How to get default cell size from a UICollectionView

If you're using the default flow layout for your collection view and have defined the cell size in Interface Builder, here's how you can retrieve the cell size programmatically. This assumes a UICollectionView outlet property called collectionView.

UICollectionViewFlowLayout *layout = (UICollectionViewFlowLayout*)self.collectionView.collectionViewLayout; layout.itemSize

You can also get at other properties like layout.minimumLineSpacing and layout.sectionInset. See UICollectionViewFlowLayout Class Reference

#iOS Development #objective-c

Which $400 Watch to Order

For the past few weeks I've been trying to decide which Apple Watch I'm going to order on midnight April 10th. Obviously, it'll be one of the Sport models. The stainless steel models are too pricey for a first generation product. Maybe after the third or fourth revision when it's much better than the current models I might be willing to spend the extra money for a stainless steel model. However, for now I just need to decide which color of Sport model I want.

The initial candidates were white, blue, and black. I ruled out white early on due to concerns about discoloration after wearing it for a long period of time. In choosing between blue and black I initially leaned towards blue. As I get older I prefer "lightness" in my life. The silver aluminum and light blue band is certainly lighter, and more cheery and fun looking than the all black model.

I also appreciate that the silver aluminum case is honest about what it is. It looks exactly like the material its made out of and nothing more. The black aluminum model seems to be covering up its true roots. Like it's trying to be something fancier than what it really is. For a while I had my mind set on blue. If I was only going to wear the Apple Watch inside my own house then I'd be completely comfortable with that choice.

However, I'm also going to be wearing it in public. That blue band and silver aluminum case will scream to everyone around me, "Look at me! I'm an Apple Watch! Check out this playful bright blue band!". I don't want my watch to yell at the people around me. I want it to look nice but not draw undue attention to itself. So I switched to black. I think I'll feel more comfortable wearing that in public. If someone looks closely enough and knows what to look for they'll see it's an Apple Watch. Otherwise, it'll look just like a normal watch and most people won't give it a second thought. Plus, that black aluminum does indeed make it look a notch more elegant than the other Sport models. I'm down with that. It's black for me.

#apple watch

How Far Will the Gold Go?

The new MacBook is an amazing feat of engineering and a beautiful machine. I find it interesting not because I want one for myself though. I'm a professional and actually need more speed, more memory, more storage, more screen, and more ports. The MacBook Pro is the machine for me. There's a reason why they put "Pro" in the name. Instead, the new MacBook is interesting because we know elements of it will find their way into future versions of the MacBook Pro.

The Force Touch trackpad is already in the 13" MacBook Pro. It's seems a given it'll eventually make it to the 15" as well. The new keyboard will probably make its way to the MacBook Pro as well. I'm also curious to see if the different color options will be available as well or if that will remain strictly a consumer MacBook thing. If gold and black make it to the MacBook Pro will the iMac eventually get those colors too?

We'll probably get new bluetooth keyboards and track pads at some point in the future. It'll be interesting to see if those come in gold and black as well. Just like the mouse who wants some milk to go along with his cookie if you have a gold laptop up on a stand you're probably going to want a gold keyboard and track pad to go with it.

Display Space Versus Sharpness

I recently got my first Retina MacBook Pro when I started my new job last November. It is an amazing screen and I planned to use it as my primary display from that point forward. Never again, would my eyes look at a chunky non-Retina screen again.

However, a 15" inch screen isn't very large and Xcode really wants a lot of space. Especially if you're working with iPad storyboards. Nevertheless, I stuck with my Retina-first policy in an effort to reset my default expectations to fit a 15" screen.

Yesterday, just for kicks, I decided to hook up my 27" external monitor as a primary display and position the Retina MacBook Pro off to the side. I've discovered that I really do value the extra space over the sharpness of the Retina display.

It feels so much more "freeing" to have lots of space to arrange windows in. It feels great to let Xcode stretch itself out as big as it needs to be. On the 15" screen I find myself actively hiding/showing Xcode's various panes (Navigator, Editor, Inspector, Console) to optimize screen space for whatever task I happen to be doing at the time. With the 27" screen I can let all the panes be visible all the time with no ill effect. I'm not distracted with hiding/showing stuff and can focus on what I'm doing instead of window management.

Even though the pixels are chunkier, the benefits of the extra space outweight the sharpness of the Retina display for now. At least until Apple releases a standalone 5K display and a MacBook Pro that can drive it, that is.

The most important Xcode article I've read this year. Knowing about the callers menu is a game changer for my current project.

Jenkins Detached Head

If you’re using the Git Client Plugin with Jenkins you may run into a detached head situation. Using version 1.15.0 of the plugin, the most straight forward way to deal with this is to select the “Add” button in the Additional Behaviors section and choose the “Checkout to specific local branch” item in the drop-down list. Then enter the name of the branch you’re working with. I keep things simple and easy by making this the same as the branch name in “Branches to build”.

#jenkins #git #detached head

Which Big iPhone?

I’m dealing with the very real first-world problem of deciding which bigger iPhone I want.

The case for the 5.5”

Optical Image Stabilization — Apple says it’s supposed to help in low-light conditions which would be almost all of my photographs. Can I be satisfied knowing I didn’t go for the absolute best camera available especially when I would supposedly benefit from it quite a bit?

Bigger and easier to read text for my aging eyes. I can bump up my default Dynamic Text size and still have lots of room for the bigger text.

It might be a reasonable size for reading eBooks for extended periods of time. Also, a 6 ounce iPhone 6 is a heck of a lot lighter than a 1 pound iPad Air. A big benefit when reading in bed.

Better battery life than the 4.7”. But I don’t know if it’s going to enough to break the 1-day barrier which isn’t a problem for me now anyway. The first iPhone that I only need to charge every other night is probably still a ways off.

401 PPI display! I probably won’t be able to tell a difference though. I already can’t discern pixels at 326 PPI which the 4.7” has. (See aging eyes from above.)

That landscape stuff in iOS 8 looks kind of cool. It might make dealing with email on the iPhone more pleasant.

Sharing cool movie trailers, funny cat videos or Weird Al music videos with the kids means a bigger screen to huddle around. I know there’s Air Play but many times it’s much easier to say, “Hey kids! Come check this out!” with zero fussing.

Games. Despite having an iPad I do most of my gaming on my iPhone because it’s the one device I always have with me. Monument Valley would look pretty cool on a 5.5” screen.

I’m not an old person. Not mentally anyway. Young people boldly move forward and eagerly try new things. If I’m going to be getting a bigger phone anyway then why not get the one that’s really bigger instead of one that’s just a little bit bigger. I can always get a smaller one in two years if I really don’t like the 5.5” size.

The case against the 5.5”

It’s much bigger. It might be unwieldy. The Reachability feature looks like it handles the vertical stretching problem but stretching my thumb horizontally across the bottom of the 5.5” screen is going to be nearly impossible. How often do I do this though?

Heavier. But the 4.7” is heavier than the current iPhones too. The 5.5” is just more heavier.

I might look like a tool using a giant iPhone in public. We all like to think we’re independent mavericks who don’t care what other people think but it does matter how you look and how other people perceive you. We all care about what kind of image we’re projecting to other people. It just a matter of how far down that path you go and how much you depend on the approval of others for your own happiness. There’s a difference between curating your outward image and being dependent on the approval of others for your happiness. Anyway, there are enough big Android phones in the wild that I think it’s already socially acceptable. I almost never hold my iPhone up to my face anyway.

It’s $100 more expensive. I could use that money toward an Apple Watch next year. Or 100 songs on iTunes. Or 20-ish movies on iTunes. Or a year of 200GB iCloud storage, for both me and my wife. There’s so many ways to give Apple my money!

#iphone6

sb-marilyn

Yes, yes I did just make exact to size mock ups of the iPhone 6 and iPhone 6 plus. #decisions Here’s a link to my VERY crude templates with iPhone front image only. Also Watch sizes from what little info was given. http://d.pr/f/SOt2

Trending Blogs

Recently Viewed Blogs

Sandmoose