Archive for 'Programming'

Git Stuffed

Don’t think we’re ever going to git on board with the rest of the world’s VCS of choice these days, just curmudgeonly mutter forever about the near-infinitely superior Veracity languishing in near-total obscurity; but if you’re going to git on with other people these days you don’t have much choice it seems, and hey we can actually git down with SourceTree these days not too badly (2.0 is just out, and looking sharp) … except when it totally trashes an Xcode project merge. Oh, right, that’s like EVERY @(#$&@%^!!! SYNC it seems. And then all in earshot git treated to a choice Troll Rant™ about burning it to the ground and then nuking it from orbit and then it’ll be time to really git serious. If you have more than one person trying to git any real work done, we’re sure you know the feeling.

But from one Michael Krause comes word of a handy-looking little tool for possibly reducing your blood pressure in these situations:

xcodeprojer

xcodeprojer is a Python script that brings your project.pbxproj files in order. It can transform any kind of JSON, XML or plist format into an internal representation and generate exactly the same commented plist format that Xcode itself uses.

Without relying on Xcode at all this can be used for tasks like this:

  • Ensure the canonical plist format of the project before checking in a new version.
  • Perform custom modifications via these steps
    1. transform your project into JSON or XML.
    2. manipulate the JSON or XML object tree in a language of your choice.
    3. emit JSON or XML and let xcodeprojer create the proper plist for you.
  • Perform custom modifications directly via Python with xcodeprojer as a module.
  • Repair broken projects, a failed parse reports the line and column where the parser failed.
  • Doing all of the above even on a non-Mac computer because it is written in pure Python…

That should reduce our falling back to the git pretty workflow every time two people work at the same time. We hope.

A considerably lesser but still regularly occurring problem we git annoyed by is figuring out how to git a build number that makes some kind of sense automatically. And we can git you some help with that too: here is the risibly named post

The Best of All Possible Xcode Automated Build Numbering Techniques

This script uses the PlistBuddy command line tool to edit the build number of the Info.plist in the /foo/DerivedData/bar directory, the target’s build directory. This is why git isn’t dirtied when the build number changes. It doesn’t matter what you’ve entered in your Info.plist screen in Xcode. It also updates the build number for every build, not just the first build after a total clean … It uses the git commit count for the build number, but if it detects that we’re using our Debug build configuration in Xcode, it suffixes the build number with the current git branch name. This avoids potential build number collisions across feature branches under simultaneous development

That sounds … well, tolerable, actually, can’t think of a number-related problem we’ve had that wouldn’t have avoided.

And as a final note, it seems that even command line git these days can be somewhat more advanced of interface than banging two rocks together in the dark and hoping sparks fly out:

Git Tutorial – Git Fu With The Command Line

UPDATES:

Tool: Handy iPhone And iPad App For Updating Code In A Git Repo On The Go

Continue Reading →
0

Apple-Paying The Piper

So between squeeing over the watches and squealing over the bendy phones and free music and all the other nonsense that just seems to get sillier all the time, anybody remember that other little thing Apple squeezed into their do? Haven’t seen very much discussion of that yet, but we’re kinda suspecting here it might turn out to be more of a Big Deal than most people are expecting right now. Here’s an excellent article to catch you up if you’ve been in the distracted by the shiny things crowd:

How Apple Pay works and why it matters for developers

Background: Clover and First Data (our parent company) have been working with Apple to prepare for the launch of Apple Pay to support developers, merchant acquirers, and issuing banks (see First Data’s press release). Clover is enabling all merchants to accept In-App payments, and will be In-Person/NFC enabling all merchants as well (see https://www.clover.com/features/iphone). Here’s a bit of how it works from a developer’s perspective, and why it matters…

Apple Pay marks the first time a popular operating system is making payments a platform service for real-world, non-digital-good transactions, in a broad, inclusive manner that is compatible with the mainstream payments processing industry. At Clover we’re particularly excited because we believe it opens up lightweight apps that can interact and transact with small-and-medium brick-and-mortar restaurants. By lightweight, I mean that these apps won’t need to maintain a user database, require user logins, worry about getting cards on file, or being an unwilling payment aggregator. i.e., it will be at least 10x easier. I expect a huge amount of innovation in real-world mobile commerce as a result over the coming years because of the revolution that Apple Pay is starting…

Generally we tend to dive headlong into Full On Mockery Mode™ soon as we see “revolution” touted in this industry, as perhaps the Dear Longtime Reader may have noticed here and there; but yeah, in this particular case, ok, this just could turn out enough of a thing that “revolution” would only be mild hyperbole. If the details are a bit eye-glazing to you, we’ll tl;dr here from the comments:

This article does explain the advantage Apple Pay has over other eWallet systems. By utilizing Network-Level Tokenization, Apple has integrated with all gateways, processors, issuers, and acquirers in the current payment scheme by negotiating directly with Visa, MasterCard, AMEX, Bank of America, JP Morgan Chase, Wells Fargo, and the list goes on…

This isn’t something that other eWallets have done. Thus, why Apple Pay will be around… and others won’t.

We’re pretty firmly on board with that prognostication.

There’s some more perspectives worth reading collected over at Michael Tsai’s blog.

UPDATES:

“Starting today, any Stripe user can begin accepting Apple Pay in their iOS apps.”

Continue Reading →
0

Xcode 6 Custom Interface Builder Previews

Ah, yes. This was the thing that kept us scrabbling on by our fingernails to developing applications in PowerPlant (remember that?) long past when everyone else who could read the writing on the wall had long since jumped ship to Cocoa; not being able to lay out your UI with preview seemed so hopelessly retrograde to us that there was no way we’d work without Constructor unless we had to.

And, well, then Carbon never made it to 64-bit, so we had to for a decade. Funny how these things go.

So although we can’t quite work ourselves up to be quite as celebratory as their effort probably deserves, it does deserve celebration that, FINALLY, our workflow can now include

BUILDING CUSTOM UI ELEMENTS WITH IBDESIGNABLE [AND IBINSPECTABLE]

These two new keywords have been added to Xcode 6 to preview our custom views directly through Interface Builder. That’s right: this is a dramatic improvement in terms of re-usability, sharing, and, in a way, testing.

We prefix our class with the @IBDesignable keyword to inform Interface Builder that the class’ instances will try to design themselves when added to the storyboard…

Then, prefixing any properties of the class with @IBInspectable, we ensure that Interface Builder can read and write the value of these properties directly in the inspector view…

The previous code will end up returning new fields in Interface Builder to setup that property … and in the ViewController in the storyboard we get a preview of the view like for any other UIKit component:

That’s pretty much it really, but read the whole thing for a good walkthrough!

h/t: ManiacDev!

UPDATES:

Tutorial: Step-By-Step Guide To Creating A Great Looking Custom UI Control In Swift

Continue Reading →
0

iPhone 6 Screen Apoplexia

Starting to feel like you’re totally losing the plot now that your iOS app can find itself living in five different point dimensions,

  • 320 x 480
  • 320 x 568
  • 375 x 667
  • 414 x 736
  • 768 x 1024

and three different point scales,

  • @1x: up to iPhone 3GS/iPod 3G/iPad 2/iPad mini 1
  • @2x: everything later except
  • @3x: iPhone 6 Plus

and even a logical to physical downsampling discrepancy on top of that? Here, go check this out to explain it:

iPhone 6 Screens Demystified

To demonstrate different rendering of pixels on various devices, we compare how 1-point wide line is rendered on

Original iPhone – without retina display. Scaling factor is 1.

iPhone 5 – with Retina display, scaling factor is 2.

iPhone 6 Plus – with Retina display HD. Scaling factor is 3 and the image is afterwards downscaled from rendered 2208 × 1242 pixels to 1920 × 1080 pixels.

The downscaling ratio is 1920 / 2208 = 1080 / 1242 = 20 / 23. That means every 23 pixels from the original render have to be mapped to 20 physical pixels. In other words the image is scaled down to approximately 87% of its original size…

TL;DR: If you haven’t yet … it’s time to buy PaintCode!

UPDATES:

Using Vector Images in Xcode 6

Xcode 6: Live Rendering, Visual View Debugging, and Swift

Responsive iOS Buttons with PaintCode

Adaptive Layouts For iPhone 6

How to design for thumbs in the Era of Huge Screens

Adaptive user interfaces

What iOS 8 Means for App Design

What’s our Vector, Victor?

iPhone 6 Plus Pixel Peeping

Continue Reading →
2

Tip: Xcode 6 Bundle Signing

Having this problem with your shiny new Xcode 6 GM?

Screen Shot 2014-09-10 at 8.12.00 AM.png

Problem also discussed here.

Solution 1:

Adding the `–deep` flag to “Other Code Signing Flags” (OTHER_CODE_SIGN_FLAGS) got me around this.

Solution 2:

Delete Info.plist inside the bundle if it’s only a resource package.

(And if there’s some reason you need it, at least delete the ‘CFBundleExecutable’ key.)

Good luck with that!

Continue Reading →
0

Layout Best Practices

Read of the day while you’re nervously waiting to see what will need panic rewrites tomorrow:

Screen Shot 2014-09-08 at 8.33.11 AM.png

Don’t think there’s anything in there actually covered by NDA at this point, but we’ll just refer you there for the beta software feature discussion bits. The important parts are not new, but they’ve been widely disregarded to date, at least they sure are in software we get stuck maintaining:

  • Nowhere should you be using screen or window size to do layout. Your view bounds should be the only consideration.
  • At load time, as called out above, you’re not in a hierarchy yet. Therefore you do not know what your view bounds will be. This has always been a thing for any view contained by a view with its own layout, and became more of a thing with iOS 7 when your views developed an inclination to jump under the status bar behind your back, but rumour has it that it will be a big thing very soon.
  • layoutSubviews is the best place to be putting your legacy-type frame setting code.
  • updateViewConstraints is the correct place to figure out your interface for reals; if you’ve so far avoided auto layout, now is a superb time to get on that.

Hopefully none of this is any particular news to you, so getting all those legacy codebases copacetic with whatever novel execution environments actually appear tomorrow from the collection of swirling rumours should be no problem, right?

Continue Reading →
0

Standards Marked Downer

Here’s an interesting case study on how to not make friends:

Standard Flavored Markdown

It took a while, but I’m pleased to announce that Standard Markdown is now finally ready for public review.

standardmarkdown.com

It’s a spec, including embedded examples, and implementations in portable C and JavaScript. We strived mightily to stay true to the spirit of Markdown in writing it. The primary author, John MacFarlane, explains in the introduction to the spec

Well, that all sounds well and good, aside from having a snicker at the obligatory xkcd 927 mention, doesn’t it? Um, no. After not too many yay! great! finally! comments on the above, we start getting

… We all use Markdown, not just you and your pals. It isn’t yours to do with as you please. Create something new, and respect prior art…

… Besides that, the hubris involved in calling your fork standard is a bit much…

… any such effort needs to do so under a new name. Not to do so is confusing to users and needlessly hostile toward John Gruber…

… Ignoring this term means you’ve broken the deal, and opens you up to a copyright infringement lawsuit…

Oops. The comments devolve from that last point into wrangling over the legal definition of ‘derivative’ … but if you’re down to arguing on that level, well, you’ve already lost, haven’t you?

Screen Shot 2014-09-05 at 2.59.35 PM.png

… yeah, that’s a pretty darn good example of exactly the kind of reaction you want your new project to avoid at all costs.

Now, we generally try to actively avoid pointless drama like this — what led us to this donnybrook was actually a handy looking new pod

laptobbe/TSMarkdownParser

TSMarkdownParser is a markdown to NSAttributedString parser for iOS implemented using NSRegularExpressions. It supports many of the standard tags layed out by John Gruber on his site Daring Fireball. It is also very extendable via Regular Expressions making it easy to add your own custom tags or a totally different parsing syntax if you like…

which looked like a particularly nicely lightweight way to manage some easy attribution of strings. ‘Course, there’s lots of other implementations around too, if that particular one isn’t adequate to your needs. Or you could always start your own flavour. “Definitive Markdown”? “Authoritative Markdown”? Those aren’t taken yet!

UPDATES:

And the first attempt was to try “Common Markdown” and that didn’t work either … so now it’s CommonMark!

Continue Reading →
0

Terminally Illin’

Now here’s a veritable novelette on a topic you almost certainly know less about than Craig Hockenberry does:

The Terminal

I’ve been using the Unix command line since 1983 and like most software developers, the Terminal app is a permanent fixture in my Dock. Over the years I’ve learned a lot of things that make working in this environment more productive, but even old dogs like me are constantly learning new tricks.

As much as I love them, these long “trick lists” on Stack Overflow have a problem: they’re poorly organized with little narrative describing why you’d want to use a technique. This long homage to the command line is my attempt to remedy that situation…

As developers, we live and die by our clipboard. Code and data moves between different contexts all day long thanks to Cocoa’s NSPasteboard. It should not be surprising that pbcopy and pbpaste are simple and powerful integration points at the command line…

Most apps have preferences that are managed by NSUserDefaults. You can easily view or modify these settings from the command line using the defaults command…

Speaking of designers, one of the best ways to communicate with them is through pictures. The screencapture tool let’s you do some things you can’t do using the Command-Shift-3 and Command-Shift-4 keys in the Finder…

Spotlight search on the Desktop has become an essential tool for developers. We find code, documentation, messages and all kinds of information that’s related to our projects using Command-space and a simple text field. Would it surprise you to know that you can do more complex searches of the same dataset using the command line?…

It’s incredibly handy to control your desktop apps using the shell. Since AppleScript has always been the best way to control apps, it makes sense that there would be a command line tool. The osascript tool is one the Swiss Army would love…

A lot of the files we deal with are executable. Even if symbols have been stripped from the app, you can still infer a lot of information by looking at the null terminated strings present in the data…

If you’re developing for Mac or iOS, you already know how damn useful Instruments is for tracking application behavior. DTrace is the framework that makes all that possible. Well, take a look at all the stuff in the shell that “uses DTrace”…

Have you ever had a folder full of files that you’ve wanted to access through a web browser? You could setup Apache to do this by editing the httpd.conf file, or just enter the following command in the folder you want to access…

Data is never in the format you need it, is it? The shell’s notion of standard input and output has always made it great for doing data conversion. Here are some tools that you may not know about…

Pretty much guarantee you’ll find a whole bunch of somethings you didn’t know in there!

Continue Reading →
0

Tip: Open Settings URL

Oops, we managed to miss this in the WWDC videos:

Open Settings URL

A quick tip I picked up from WWDC 2014 session 715 on User Privacy. Starting with iOS 8 there is now a settings launch URL to send the user directly to the settings for an App. The code snippet below will do the trick:

[[UIApplication sharedApplication] openURL:[NSURL URLWithString:
UIApplicationOpenSettingsURLString]];

If you’ve got any functionality that the user can say no to, it’s guaranteed they will, and then they’ll send you angry letters and one-star reviews when it doesn’t work, you’ve all been there right? So make sure you put on your iOS 8 upgrade checklist putting in a helpful remediation option wherever deniable things can fail!

Continue Reading →
0

Storyboard Launch Images

So, you been fearing what the likely new @3x sizes are going to do to your seven and counting launch image requirements?

Well, looks like all that fuss may be going away soon:

Replacing Launch Images with Storyboards

An Interface Builder-Based Launch Screen

In Xcode 6, there is another option. You can specify a storyboard whose initial view controller will then be used as the appʼs launch screen. This is how:

  1. Create a blank storyboard file named LaunchScreen.storyboard.
  2. Go to your target settings and, on the General tab, select the storyboard as your Launch Screen File. Xcode will add a corresponding UILaunchStoryboardName key to your appʼs Info.plist. When this key is present, Xcode will prioritize it over any launch images you might have set.
  3. Add a view controller scene to the storyboard. Add some subviews to the scene and position them with constraints. When you launch the app on a device, the OS should use the scene as the launch screen.

One Storyboard for All Screen Sizes

You can use the new adaptive UI features in Interface Builder to fit your layout to different screen sizes. If your scene requires screen-size-specific images, use asset catalogs to define different images per size class. Note that you can not only adjust constraints for different size classes, you can also remove selected views from a specific size class entirely by deselecting the Installed check box. See WWDC session 411 for details.

Also Works with NIBs

Despite the name of the UILaunchStoryboardName key, this also seems to work with NIB/XIB files containing a single view. When you open such a XIB file in Xcode, the File Inspector displays a check box named Use as Launch Screen, which is not there for storyboards…

There’s a number of partially-implemented caveats at the moment, but looks like a solid reason to get up to speed on those new adaptive UI features, because as they say

Screen Shot 2014-08-30 at 9.00.52 PM.png

Speaking of which, here’s a handy UICustomResolutions extension for UIWindow to help testing that!

h/t: iOS Dev Weekly!

UPDATES:

Yup, it’s 667×375@2x(1334×750) and 414×736@3x(2208×1242) just as predicted, and new @3x icon sizes to match!

As for xib/storyboards, they’re required for the new devices:

You use a launch XIB or storyboard file to indicate that your app runs on iPhone 6 Plus or iPhone 6.

Oh, wait no: You can also add raster images to the new LaunchImage.xcassets buckets.

Continue Reading →
0
Page 2 of 97 12345...»