<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Fully Typed</title>
    <link>http://fullytyped.com/</link>
    <description>Recent content on Fully Typed</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <copyright>Colin Reisterer</copyright>
    <lastBuildDate>Sun, 03 Mar 2019 17:12:44 -0500</lastBuildDate>
    
	<atom:link href="http://fullytyped.com/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Multi project strings With Twine and R.swift</title>
      <link>http://fullytyped.com/2019/03/03/multi-project-strings-with-twine-and-r/</link>
      <pubDate>Sun, 03 Mar 2019 17:12:44 -0500</pubDate>
      
      <guid>http://fullytyped.com/2019/03/03/multi-project-strings-with-twine-and-r/</guid>
      <description>&lt;div class=&#34;post-highlights&#34;&gt;
    &lt;h2 id=&#34;highlights&#34;&gt;Highlights&lt;/h2&gt;

&lt;ul&gt;
&lt;li&gt;Create a shared strings file for &lt;a href=&#34;https://github.com/scelis/twine&#34;&gt;Twine&lt;/a&gt;, with all strings and translations, for all your projects&lt;/li&gt;
&lt;li&gt;Generate per project and platform strings files to support all languages, such as Localizable.strings files on iOS&lt;/li&gt;
&lt;li&gt;On iOS, generate strongly typed code based on Localizable.strings files to use in your UI using &lt;a href=&#34;https://github.com/mac-cain13/R.swift&#34;&gt;R.swift&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;In your Xcode project(s), set up Run Script build phase steps to handle Localizable.strings and &lt;a href=&#34;https://github.com/mac-cain13/R.swift&#34;&gt;R.swift&lt;/a&gt; code generation&lt;/li&gt;
&lt;/ul&gt;

&lt;/div&gt;

&lt;h2 id=&#34;introduction&#34;&gt;Introduction&lt;/h2&gt;

&lt;p&gt;Inconsistencies in copy are a drag. Working on mobile apps across iOS and Android, it seems inevitable that things are going to get out of sync, whether it&amp;rsquo;s different capitalization on a title &lt;em&gt;Um, the Android app says &amp;ldquo;Hello, world!&amp;rdquo; but iOS says &amp;ldquo;Hello, World!&amp;rdquo;?&lt;/em&gt; or confirmation button copy &lt;em&gt;Did we mean to use &amp;ldquo;OK&amp;rdquo; or &amp;ldquo;Okay&amp;rdquo;? I see both&lt;/em&gt;. &lt;a href=&#34;https://github.com/scelis/twine&#34;&gt;Twine&lt;/a&gt; is an open source command line tool that aims to solve this problem, by ensuring we conform to the &lt;a href=&#34;https://en.wikipedia.org/wiki/Don%27t_repeat_yourself&#34;&gt;DRY&lt;/a&gt; principle and only maintain a single source of string truth!&lt;/p&gt;

&lt;p&gt;For the purposes of this article, we&amp;rsquo;ll be starting with an app that lists phrases in English only, to a fully localized app that supports multiple languages, getting all translations from a Twine data file that could be shared with an Android app!
Additionally, we&amp;rsquo;ll take it a step further and use &lt;a href=&#34;(https://github.com/mac-cain13/R.swift)&#34;&gt;R.swift&lt;/a&gt; to generate strongly typed localized string references from the &lt;code&gt;Localizable.strings&lt;/code&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Unit testing views and view controllers on screen</title>
      <link>http://fullytyped.com/2019/01/07/on-screen-unit-tests/</link>
      <pubDate>Mon, 07 Jan 2019 21:50:37 -0500</pubDate>
      
      <guid>http://fullytyped.com/2019/01/07/on-screen-unit-tests/</guid>
      <description>&lt;div class=&#34;post-highlights&#34;&gt;
    &lt;h2 id=&#34;highlights&#34;&gt;Highlights&lt;/h2&gt;

&lt;ul&gt;
&lt;li&gt;Short circuit your app launch when unit testing. This leaves the application window free to use to test UI components.&lt;/li&gt;
&lt;li&gt;Test your screens as you develop using XCTestCase! By temporarily adding pauses in test cases, can manually test and interact with views in isolation.&lt;/li&gt;
&lt;li&gt;When manual testing is complete, use snapshot testing to record and verify view appearance - with a bonus of having visual documentation of your screens&lt;/li&gt;
&lt;/ul&gt;

&lt;/div&gt;

&lt;h1 id=&#34;introduction&#34;&gt;Introduction&lt;/h1&gt;

&lt;p&gt;Apple provides the XCTest framework for testing iOS and MacOS apps, and it is a powerful, flexible framework for asserting our apps function properly. In regards to unit tests, testing isolated views and view controllers is possible, though arguably a little clunky. For example, when testing view controllers, you need to remember to load the view. The generally accepted answer is to access the view, as the getter will trigger the load:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre class=&#34;chroma&#34;&gt;&lt;code class=&#34;language-swift&#34; data-lang=&#34;swift&#34;&gt;&lt;span class=&#34;kd&#34;&gt;let&lt;/span&gt; &lt;span class=&#34;nv&#34;&gt;viewController&lt;/span&gt; &lt;span class=&#34;p&#34;&gt;=&lt;/span&gt; &lt;span class=&#34;n&#34;&gt;MyViewController&lt;/span&gt;&lt;span class=&#34;p&#34;&gt;()&lt;/span&gt;
&lt;span class=&#34;kc&#34;&gt;_&lt;/span&gt; &lt;span class=&#34;p&#34;&gt;=&lt;/span&gt; &lt;span class=&#34;n&#34;&gt;viewController&lt;/span&gt;&lt;span class=&#34;p&#34;&gt;.&lt;/span&gt;&lt;span class=&#34;n&#34;&gt;view&lt;/span&gt;  &lt;span class=&#34;c1&#34;&gt;// load the view for testing&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;However, this doesn’t actually make the view visible, or add it to a window or view hierarchy. Instead, we can create a visible window in the running application when running tests (either simulator or physical device) and add our view controller’s view, or isolated view, to test there.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>How To: Unit Test Without Running The Entire App</title>
      <link>http://fullytyped.com/2019/01/06/unit-test-without-entire-app/</link>
      <pubDate>Sun, 06 Jan 2019 22:24:09 -0500</pubDate>
      
      <guid>http://fullytyped.com/2019/01/06/unit-test-without-entire-app/</guid>
      <description>&lt;p&gt;By default, running tests with XCTest launches and runs the app alongside the tests, as they run in the same process. For unit tests, this is generally undesirable as a) it slows down unit tests and b) unit tests are about testing isolated components, not the complete application. With a few lines of code, you can “short circuit” your app launch when running unit tests (safely keeping the code out of production). This also has the added benefit of freeing up the screen for &lt;a href=&#34;http://fullytyped.com/2019/01/07/on-screen-unit-tests/&#34;&gt;Unit Testing View Controllers and Views.&lt;/a&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Animating Modal View Controller Transitions</title>
      <link>http://fullytyped.com/2018/12/12/custom-modal-animations/</link>
      <pubDate>Wed, 12 Dec 2018 20:41:38 -0500</pubDate>
      
      <guid>http://fullytyped.com/2018/12/12/custom-modal-animations/</guid>
      <description>&lt;div class=&#34;post-highlights&#34;&gt;
    &lt;h2 id=&#34;highlights&#34;&gt;Highlights&lt;/h2&gt;

&lt;ul&gt;
&lt;li&gt;Avoid modifying the views of the presenting or presented view controllers during the animation. UIView snapshots are your friend!&lt;/li&gt;
&lt;li&gt;Custom transition animations don&amp;rsquo;t require &lt;code&gt;modalPresentationStyle = .custom&lt;/code&gt; unless the presentation itself needs to be customized, not just the transition. (Just remember to add the &lt;code&gt;to&lt;/code&gt; view controller&amp;rsquo;s view to the transition context)&lt;/li&gt;
&lt;li&gt;Be sure to set the frame of the presented view controller to the bounds of the container view, otherwise you may run into subtle bugs, such as layout issues when the in-call status bar is presented.&lt;/li&gt;
&lt;/ul&gt;

&lt;/div&gt;</description>
    </item>
    
    <item>
      <title>Updating Xcode Managed Provisioning Profiles</title>
      <link>http://fullytyped.com/2017/08/01/updating-xcode-managed-provisioning-profiles/</link>
      <pubDate>Tue, 01 Aug 2017 20:09:51 -0400</pubDate>
      
      <guid>http://fullytyped.com/2017/08/01/updating-xcode-managed-provisioning-profiles/</guid>
      <description>&lt;p&gt;TL;DR: clean out &lt;code&gt;~/Library/MobileDevice/Provisioning\ Profiles&lt;/code&gt;&lt;/p&gt;

&lt;p&gt;Apple has been recommending &lt;a href=&#34;https://developer.apple.com/library/content/qa/qa1814/_index.html&#34;&gt;automatic code signing&lt;/a&gt; for some time, and once Xcode 8 was released I am happy to say that most of its aspirations have been realized. My projects tend to have somewhat complex Build Configurations to support Integration, Staging, and Production builds of each app, so having &lt;em&gt;most&lt;/em&gt; of the provisioning and cert madness automated is a big relief. Prior to Xcode 8, I was manually managing provisioning profiles for each configuration which can be quite a burden if frequent provisioning profile updates are made.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>About</title>
      <link>http://fullytyped.com/about/</link>
      <pubDate>Sat, 22 Jul 2017 20:51:15 -0400</pubDate>
      
      <guid>http://fullytyped.com/about/</guid>
      <description>About Hi! Welcome to Fully Typed, a site for all my ramblings related to software development. I focus on iOS App Development; I am currently the lead iOS Engineer at Starry.</description>
    </item>
    
  </channel>
</rss>