-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[ci skip] Automated deployment to GitHub Pages on 1727329652639
- Loading branch information
0 parents
commit 6533781
Showing
37 changed files
with
3,033 additions
and
0 deletions.
There are no files selected for viewing
62 changes: 62 additions & 0 deletions
62
2014/07/25/objective-c-prefixes-a-thing-of-the-past/index.html
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,62 @@ | ||
| <!DOCTYPE html> | ||
| <html lang="en"> | ||
| <head> | ||
| <title>Objective-C prefixes: a thing of the past? - Scott Berrevoets</title> | ||
| <meta charset="utf-8" /> | ||
| <meta name="viewport" content="width=device-width, initial-scale=1.0" /> | ||
|
|
||
| <meta name="description" content="Some insights about whether Objective-C prefixes are still necessary" /> | ||
|
|
||
|
|
||
| <link rel="stylesheet" type="text/css" href="../../../../theme/css/style.css" /> | ||
| </head> | ||
|
|
||
| <body id="index" class="home"> | ||
| <header id="banner" class="body"> | ||
| <h1><a href="../../../../">Scott Berrevoets</a></h1> | ||
|
|
||
| <ul id="social"> | ||
| <li><a href="https://github.com/sberrevoets"><img src="../../../../theme/images/github.svg"></a></li> | ||
| <li><a href="https://linkedin.com/in/sberrevoets"><img src="../../../../theme/images/linkedin.svg"></a></li> | ||
| <li><a href="https://hachyderm.io/@ScottBerrevoets"><img src="../../../../theme/images/mastodon.svg"></a></li> | ||
| <li><a href="mailto:[email protected]"><img src="../../../../theme/images/mail.svg"></a></li> | ||
| </ul> | ||
| </header><!-- /#banner --> | ||
| <nav id="menu"><ul> | ||
| <li class="active"><a href="../../../../">Blog</a></li> | ||
| <li><a href="../../../../about.html">About</a></li> | ||
| </ul></nav><!-- /#menu --> | ||
| <section id="content" class="body"> | ||
| <header> | ||
| <h2 class="article-title">Objective-C prefixes: a thing of the past?</h2> | ||
|
|
||
| <time class="published" datetime="2014-07-25T00:00:00-07:00"> | ||
| 25 July 2014 | ||
| </time> | ||
| </header> | ||
| <div class="article-content"> | ||
| <p>This past week, there was, again, a lot to do about Objective-C and prefixing. To most iOS developers, the story sounds familiar: one camp is strongly in favor, another camps is strongly against, and a third camp couldn't really care less.</p> | ||
| <p>Unless I'm unaware of any other platforms where the discussion was also a hot topic, this time I was at least a little responsible for instigating a debate that will never see a clear winner, with the following tweet:</p> | ||
| <blockquote class="twitter-tweet" lang="en" align="center"><p><a href="https://twitter.com/bobmccune">@bobmccune</a> <a href="https://twitter.com/invalidname">@invalidname</a> Also no option to enter class prefix anymore, even for Objective-C projects</p>— Scott Berrevoets (@ScottBerrevoets) <a href="https://twitter.com/ScottBerrevoets/statuses/492012762940588033">July 23, 2014</a></blockquote> | ||
| <script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script> | ||
|
|
||
| <p>Let's first clear up that Swift doesn't <strong>need</strong> to have class prefixes, because it has built-in support for namespacing through modules. From what I read, earlier Xcode 6/Swift betas did not have module support, but at least we know it's coming before 1.0 hits.</p> | ||
| <p>However, this doesn't solve any of the problems Objective-C has, and so it was surprising to see this field was removed when creating a new Objective-C project. You can still set this prefix per project <strong>after</strong> you create it, but since most Xcode templates create source files for you, those files will be created without a prefix.</p> | ||
| <p>I noticed the lack of this option, as well as the lack of a file template for Objective-C categories, back in beta 2 and immediately filed two bugs. The missing file template is as of this writing still open, but the class prefix got closed a few days later. Normally, radars aren't known for their wealth of information related to the issue the radar was filed for, but Apple Engineering made an exception this time.</p> | ||
| <blockquote> | ||
| <p>After much deliberation, engineering has removed this feature.</p> | ||
| <p>This was removed intentionally. We are no longer encouraging the use of prefixes for app code, and for frameworks, you can create a prefix in the Project Inspector after creating the project.</p> | ||
| </blockquote> | ||
| <p>Okay, so no more prefixes for app code. Didn't see that coming. Does Apple now encourage developers to start making extensive use of frameworks?</p> | ||
| <blockquote> | ||
| <p>No. If you want to use a prefix, you can set one in the project inspector. Especially for frameworks, this is easy since the template creates no source files that should be prefixed. If you really want to prefix the classes in your main app binary, you might need to rename the few that are created initially, but the recommendation is generally that frameworks should use prefixes (in Obj-C, not in Swift) to avoid namespace issues, and apps generally don't need to.</p> | ||
| </blockquote> | ||
| <p>The key part here is in the last few words: "don't need to".</p> | ||
| <p>Third-party libraries, especially frameworks that don't ship with the source code, need a prefix, because the chances of naming collisions with other code or, even worse, other libraries is significant. Users of the libraries can't (and even if they can, are likely not willing to) change the name of your classes because they collide with some other library's code.</p> | ||
| <p>"App code" on the other hand, is very unique to one particular app. It contains the UI and some of the business logic that puts your app together. Most view controllers, for example, are app code. App code is not likely to be reused, because it's very specific in what it does and is therefore unlikely to collide with other classes (assuming you name your classes well). If you think "well, this functionality may be reused in some other project", it's a great candidate for a framework!</p> | ||
| <p>I was always a big fan of the class prefixes, and while it was sometimes hard to come up with what prefix to use, I've come to actually <strong>like</strong> how they look, too. Classes that don't have a prefix feel like they're missing something. However, the guideline of "prefix frameworks, not app code" does make sense, so I will start using that from now on as well.</p> | ||
| </div><!-- /.entry-content --> | ||
| </section> | ||
|
|
||
| </body> | ||
| </html> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,146 @@ | ||
| <!DOCTYPE html> | ||
| <html lang="en"> | ||
| <head> | ||
| <title>Xcode & Objective-C Oddities - Scott Berrevoets</title> | ||
| <meta charset="utf-8" /> | ||
| <meta name="viewport" content="width=device-width, initial-scale=1.0" /> | ||
|
|
||
| <meta name="description" content="Some fun things about working with Xcode and Objective-C" /> | ||
|
|
||
|
|
||
| <link rel="stylesheet" type="text/css" href="../../../../theme/css/style.css" /> | ||
| </head> | ||
|
|
||
| <body id="index" class="home"> | ||
| <header id="banner" class="body"> | ||
| <h1><a href="../../../../">Scott Berrevoets</a></h1> | ||
|
|
||
| <ul id="social"> | ||
| <li><a href="https://github.com/sberrevoets"><img src="../../../../theme/images/github.svg"></a></li> | ||
| <li><a href="https://linkedin.com/in/sberrevoets"><img src="../../../../theme/images/linkedin.svg"></a></li> | ||
| <li><a href="https://hachyderm.io/@ScottBerrevoets"><img src="../../../../theme/images/mastodon.svg"></a></li> | ||
| <li><a href="mailto:[email protected]"><img src="../../../../theme/images/mail.svg"></a></li> | ||
| </ul> | ||
| </header><!-- /#banner --> | ||
| <nav id="menu"><ul> | ||
| <li class="active"><a href="../../../../">Blog</a></li> | ||
| <li><a href="../../../../about.html">About</a></li> | ||
| </ul></nav><!-- /#menu --> | ||
| <section id="content" class="body"> | ||
| <header> | ||
| <h2 class="article-title">Xcode & Objective-C Oddities</h2> | ||
|
|
||
| <time class="published" datetime="2014-08-10T00:00:00-07:00"> | ||
| 10 August 2014 | ||
| </time> | ||
| </header> | ||
| <div class="article-content"> | ||
| <p>Any developer that has worked with Xcode to write a little more than just "Hello, World" knows that Xcode and Objective-C have their quirks. Chances are you have heard of <a href="https://twitter.com/TextFromXcode">@TextFromXcode</a>, the Twitter handle that portrays Xcode as a high school bully in fake text conversations like this:</p> | ||
| <p><img alt="Xcode Bully" src="https://cl.ly/image/0I2P191S0Q2k/20140227.PNG"></p> | ||
| <p>But it's not always Xcode that makes Apple platform developers sometimes frown and sigh. Sometimes it's the developers themselves, sometimes it's the documentation, and sometimes a hidden gem from within Apple frameworks makes an appearance. I've compiled a short list of things I've encountered. Because it's Sunday and I didn't have anything better to do.</p> | ||
| <h2 id="uigobblergesturerecognizer"><code>UIGobblerGestureRecognizer</code></h2> | ||
| <p>Say what? A "<a href="https://github.com/nst/iOS-Runtime-Headers/blob/master/Frameworks/UIKit.framework/UIGobblerGestureRecognizer.h"><code>gobbler</code></a>" recognizer? Does it recognize when the user imitates a turkey? Well, maybe, but according to <a href="https://twitter.com/ortwingentz/status/225508227234791424">BJ Homer</a>, it is used to avoid recognition of a gesture while animations are in progress. Ah of course! Now the name "gobbler" makes perfect sense! 😶</p> | ||
| <h2 id="uitapandahalfrecognizer"><code>UITapAndAHalfRecognizer</code></h2> | ||
| <p>Speaking of gesture recognizers, there's another remarkable one that lives in the private section of UIKit: <code>UITapAndAHalfRecognizer</code>. This is a private subclass of <code>UIGestureRecognizer</code> that records "a tap and a half".</p> | ||
| <p>So what does that mean? Does it detect whether the user goes in for a second tap, but never actually touches the screen? Or does the user touch the screen ever so slightly that the second tap can hardly be considered a complete tap? Nope! This recognizer fires when a second tap stays on the screen. Not sure for what functionality Apple needs this, but it's been around since at least iOS 4, so it probably has a purpose.</p> | ||
| <h2 id="naming-is-hard">Naming is hard</h2> | ||
| <blockquote> | ||
| <p>There are only two hard things in Computer Science: cache invalidation and naming things.<br> | ||
| - Phil Karlton</p> | ||
| </blockquote> | ||
| <p>Naming <strong>is</strong> hard, but Objective-C developers always say that verbosity is one of Objective-C's strengths because its naming conventions are self-documenting. Normally I'd agree, but in this case, I think Apple may want to consider a different name.</p> | ||
| <p><a href="https://developer.apple.com/library/prerelease/ios/releasenotes/General/iOS80APIDiffs/frameworks/HomeKit.html"><code>HMCharacteristicValueLockMechanismLastKnownActionUnsecuredUsingPhysicalMovementExterior</code></a> is a brand new constant in iOS 8 and has got to be one of the longest constants that's available in iOS. Try saying it without taking a breath in the middle. </p> | ||
| <p>I found it in the iOS 8 API diffs, but it did make me wonder. What is the longest Objective-C method available in Cocoa Touch? Well, a quick Google search led to a blog post by <a href="https://initwithstyle.net/2013/10/in-search-of-the-longest-method">Stuart Sharpe</a>, who used the Objective-C runtime to generate a list of methods in the iOS 7 SDK.</p> | ||
| <p>Turns out, the longest method in the iOS 7 SDK is</p> | ||
| <div class="highlight"><table class="highlighttable"><tr><td class="linenos"><div class="linenodiv"><pre><span class="normal"> 1</span> | ||
| <span class="normal"> 2</span> | ||
| <span class="normal"> 3</span> | ||
| <span class="normal"> 4</span> | ||
| <span class="normal"> 5</span> | ||
| <span class="normal"> 6</span> | ||
| <span class="normal"> 7</span> | ||
| <span class="normal"> 8</span> | ||
| <span class="normal"> 9</span> | ||
| <span class="normal">10</span> | ||
| <span class="normal">11</span> | ||
| <span class="normal">12</span> | ||
| <span class="normal">13</span> | ||
| <span class="normal">14</span> | ||
| <span class="normal">15</span> | ||
| <span class="normal">16</span> | ||
| <span class="normal">17</span> | ||
| <span class="normal">18</span> | ||
| <span class="normal">19</span> | ||
| <span class="normal">20</span> | ||
| <span class="normal">21</span> | ||
| <span class="normal">22</span></pre></div></td><td class="code"><div><pre><span></span><code><span class="o">+</span><span class="p">[</span><span class="n">CUIShapeEffectStack</span><span class="w"> </span><span class="n">shapeEffectSingleBlurFrom</span><span class="o">:</span> | ||
| <span class="w"> </span><span class="nl">withInteriorFill</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">offset</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">blurSize</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">innerGlowRed</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">innerGlowGreen</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">innerGlowBlue</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">innerGlowOpacity</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">innerShadowRed</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">innerShadowGreen</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">innerShadowBlue</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">innerShadowOpacity</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">outerGlowRed</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">outerGlowGreen</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">outerGlowBlue</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">outerGlowOpacity</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">outerShadowRed</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">outerShadowGreen</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">outerShadowBlue</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">outerShadowOpacity</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">hasInsideShadowBlur</span><span class="p">:</span> | ||
| <span class="w"> </span><span class="nl">hasOutsideShadowBlur</span><span class="p">:]</span> | ||
| </code></pre></div></td></tr></table></div> | ||
|
|
||
| <p>Unless iOS 8 introduces a longer method name, this one takes the cake with 22 arguments and 352 characters. If you have Xcode configured to line-break at 80 characters (yes, some people still do that), this method signature alone, without any arguments, takes up 5 lines.</p> | ||
| <p>Another beauty of a method lives in Core Animation and its method signature is </p> | ||
| <div class="highlight"><table class="highlighttable"><tr><td class="linenos"><div class="linenodiv"><pre><span class="normal">1</span></pre></div></td><td class="code"><div><pre><span></span><code><span class="o">-</span><span class="w"> </span><span class="p">[</span><span class="bp">CAMediaTimingFunction</span><span class="w"> </span><span class="n">functionWithControlPoints</span><span class="o">::::</span><span class="p">]</span> | ||
| </code></pre></div></td></tr></table></div> | ||
|
|
||
| <p><code>::::</code>? Is that even valid syntax? Yes, and you call the method like this:</p> | ||
| <div class="highlight"><table class="highlighttable"><tr><td class="linenos"><div class="linenodiv"><pre><span class="normal">1</span></pre></div></td><td class="code"><div><pre><span></span><code><span class="p">[</span><span class="bp">CAMediaTimingFunction</span><span class="w"> </span><span class="n">functionWithControlPoints</span><span class="o">:</span><span class="mf">0.25</span><span class="w"> </span><span class="o">:</span><span class="mf">.50</span><span class="w"> </span><span class="o">:</span><span class="mi">0</span><span class="w"> </span><span class="o">:</span><span class="mf">1.0</span><span class="p">];</span> | ||
| </code></pre></div></td></tr></table></div> | ||
|
|
||
| <p>Was an array really too much to ask...?</p> | ||
| <h2 id="nsdate-nildate"><code>[NSDate nilDate]</code></h2> | ||
| <p>This one has made the rounds throughout the developer community before, but I'm adding it here in case you haven't seen it yet. Try running the following code:</p> | ||
| <div class="highlight"><table class="highlighttable"><tr><td class="linenos"><div class="linenodiv"><pre><span class="normal">1</span> | ||
| <span class="normal">2</span></pre></div></td><td class="code"><div><pre><span></span><code><span class="bp">NSCalendar</span><span class="w"> </span><span class="o">*</span><span class="n">calendar</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="bp">NSCalendar</span><span class="w"> </span><span class="n">currentCalendar</span><span class="p">];</span> | ||
| <span class="p">[</span><span class="n">calendar</span><span class="w"> </span><span class="n">components</span><span class="o">:</span><span class="n">NSCalendarUnitYear</span><span class="w"> </span><span class="n">fromDate</span><span class="o">:</span><span class="nb">nil</span><span class="w"> </span><span class="n">toDate</span><span class="o">:</span><span class="p">[</span><span class="bp">NSDate</span><span class="w"> </span><span class="n">date</span><span class="p">]</span><span class="w"> </span><span class="n">options</span><span class="o">:</span><span class="mi">0</span><span class="p">];</span> | ||
| </code></pre></div></td></tr></table></div> | ||
|
|
||
| <p>In the console log, you'll find the following output:</p> | ||
| <blockquote> | ||
| <p>*** -[__NSCFCalendar components:fromDate:toDate:options:]: fromDate cannot be nil<br> | ||
| I mean really, what do you think that operation is supposed to mean with a nil fromDate?<br> | ||
| An exception has been avoided for now.<br> | ||
| A few of these errors are going to be reported with this complaint, then further violations will simply silently do whatever random thing results from the nil.</p> | ||
| </blockquote> | ||
| <p>Either a grumpy Apple developer woke up at the wrong side of the bed or has a great sense of humor. In any case, I wouldn't mind if more sarcastic warnings started popping up in Xcode's console.</p> | ||
| <h2 id="defying-the-uncertainty-principle-in-ios">Defying the Uncertainty Principle in iOS</h2> | ||
| <blockquote> | ||
| <p>[I]n 1927, Werner Heisenberg stated that the more precisely the position of some particle is determined, the less precisely its momentum can be known, and vice versa.<br> | ||
| <a href="https://en.wikipedia.org/wiki/Uncertainty_principle">Wikipedia</a></p> | ||
| </blockquote> | ||
| <p>If that's true, and it's fairly safe to assume that it is, I'd avoid using <code>-[CLLocation speed]</code> for apps like radar detectors. I wonder if we're ever going to get a <code>-[CLSpeed location]</code> method, which has a more accurate speed and a less accurate location.</p> | ||
| <h2 id="xcode-at-it-again">Xcode at it again</h2> | ||
| <p>Lastly, the following is a screenshot I personally took at work that completely baffled me.</p> | ||
| <p><img src="/images/XcodeScreenshot.png" style="width: 700px; margin: 0 auto; display: block;"></p> | ||
| <p>This would not go away, even after cleaning the build folder and rebuilding. In the end I resolved the problem by running</p> | ||
| <div class="highlight"><table class="highlighttable"><tr><td class="linenos"><div class="linenodiv"><pre><span class="normal">1</span> | ||
| <span class="normal">2</span></pre></div></td><td class="code"><div><pre><span></span><code>$<span class="w"> </span>git<span class="w"> </span>stash | ||
| $<span class="w"> </span>git<span class="w"> </span>reset<span class="w"> </span>--hard<span class="w"> </span>HEAD | ||
| </code></pre></div></td></tr></table></div> | ||
|
|
||
| <p>Then, after a clean build and <code>git stash pop</code> the errors finally went away...</p> | ||
| <p>That's just a few things I've found while working with Xcode and Objective-C over the years. If you have more, please share!</p> | ||
| </div><!-- /.entry-content --> | ||
| </section> | ||
|
|
||
| </body> | ||
| </html> |
Oops, something went wrong.