Sunetos, Inc.
type: channel
description: Doug Sjoquist, Software Craftsman
date: 2015-08-01T15:51:15Z
update period: hourly
update frequency: 1
update base: 2000-01-01T12:00+00:00
generator agent: https://wordpress.org/
items: Mocking URL request with Xcode 7 UI Testing
items: Coffee, Tea, iPhone App: One of These Things is Not Like the Other
items: WWDC and The Innovator’s Dilemma
items: Renaissance IO 2013 Wrap Up
items: Cleanly Accessing the UITextView field in TWTweetComposeViewController
items: Introduction to Test Driven Development (TDD) for iOS apps (Part 2 of 4)
items: Introduction to Test Driven Development (TDD) for iOS apps (Part 1 of 4)
items: Writing Is Hard — Let’s Do Math
items: Live From 360iDev!
items: CocoaConf slides and project

Mocking URL request with Xcode 7 UI Testing
type: item
creator: dwsjoquist
date: 2015-07-20T22:56:12Z
subject: iOS Development
subject: xcode7 uitesting mocks
description: Mocking URL request with Xcode 7 UI Testing I started answering a question on Apple’s new dev forums and decided it would be better as a simple blog post. (The question was “UI Testing Mocking Data Xcode 7â€, https://forums.developer.apple.com/message/25973 ) Super simple overview of problem I want to solve: New UI Tests run in separate […]
encoded: Mocking URL request with Xcode 7 UI Testing I started answering a question on Appleâ€ s new dev forums and decided it would be better as a simple blog post. (The question was “UI Testing Mocking Data Xcode 7â€, https://forums.developer.apple.com/message/25973 ) Super simple overview of problem I want to solve: New UI Tests run in separate process from app, so my old way of mocking URL responses would no longer work I did not want any dependencies on external servers or processes I wanted to have everything about my UI Test case embedded in the test case file itself It needs to run on a CI server like Jenkins My solution (currently a work in progress) My solution is a little more involved than I would like, but I think it will work pretty well for me. To make this work, I need to do some minimal setup in the app itself to make it “test readyâ€. Since there are only two ways a UI Test case can cause changes of any kind in the app: The actual UI interaction (the main point of the test) The launch arguments for XCUIApplication #2 seemed the reasonable choice. Summary of changes to the app itself My goal was to make the minimum set of changes to the main app as I could: Added a class, TestingProxyClient, which uses NSURLProtocol to call a proxy for all network requests Added some helper functions in StartupControl.m to interpret the launch arguments passed from the test case (StartupControl also initializes the proxy client) Updated app’s main.m to call the setup function defined in StartupControl Summary of changes to the test cases My intent is for the test case to embed everything needed in the same place. Â The following are mostly finished: Start a embedded webserver to act as a network proxy (using BCDWebServer, available on github) Use launch arguments of XCUIApplication instance to pass values to the app (including the proxy address & port) Still to do: Port my existing mock data supplier to this new structure Other changes Update #3 (01-Aug-2015): Back to red…

Coffee, Tea, iPhone App: One of These Things is Not Like the Other
type: item
creator: dwsjoquist
date: 2013-10-11T02:56:33Z
subject: iDevBlogADay
subject: iOS Development
description: If you hang around iOS developers, you’ve probably heard a lament something like: Why will people pay $4.99 for a cup of coffee, but won’t buy spend $2.99 on my app? This almost evokes feelings from the great depression, doesn’t it? Once I built a railroad; now it’s done. Brother, can you spare a dime? […]
encoded: If you hang around iOS developers, you’ve probably heard a lament something like: Why will people pay $4.99 for a cup of coffee, but won’t buy spend $2.99 on my app? This almost evokes feelings from the great depression, doesn’t it? Once I built a railroad; now it’s done. Brother, can you spare a dime? Learning from bad analogies Most app makers I know consider this a bad analogy and they are correct–it is weak. Â Purchasing a cup of coffee and purchasing an iPhone app have very little in common, but examining why this analogy is weak teaches me something useful. I have been thinking1 and reading2 about this a lot lately to gain some perspective, and my hypothesis is this: There is a cognitive burden implied by a $5 app purchase that is not implied by a $5 coffee purchase. For habitual coffee purchasers, a cup of coffee is a known thing. The purchaser *knows* they will feel comfortable with it in their hand, that they will receive a boost of energy, and that once purchased they won’t have to think about it any more. This is the proverbial “no brainer” which leads to little or no hesitation. When I spend any amount of money for an app, even $0.99, I think about it differently and it adds a subconscious burden that rattles around my brain3 that makes me hesitate just long enough to trigger a different thought process. Cognitive burdens A little light went off today when I clicked on a link to Amazon for a book that sounded interesting. I am definitely the target demographic for this book, and the $7.99 price was immaterial to me so I started skimming the customer reviews. All of the “most helpful” reviews were high except for one. It was middle of the road and it’s basic claim was that the book was okay, but mediocre. That made me hesitate in clicking the “buy now” button because it changed my thinking from “this book is worth a shot” to “I don’t think I want to invest much time figuring out if which reviews are correct.” The small mental burden of thinking I would…

WWDC and The Innovator’s Dilemma
type: item
creator: dwsjoquist
date: 2013-04-26T19:34:53Z
subject: iDevBlogADay
subject: iOS Development
description: WWDC and The Innovator’s Dilemma I was reading Mark Suster’s post Understanding How The Innovator’s Dilemma Affects You today and it struck me how closely my thoughts on WWDC line up with Clay Christenson’s ideas. Not surprisingly, there has been lots of twitter and blog activity this week about Apple’s dilemma in regards to WWDC. […]
encoded: WWDC and The Innovator’s Dilemma I was reading Mark Suster’s post Understanding How The Innovatorâ€ s Dilemma Affects You today and it struck me how closely my thoughts on WWDC line up with Clay Christenson’s ideas. Not surprisingly, there has been lots of twitter and blog activity this week about Apple’s dilemma in regards to WWDC. Is it broken? Does it need fixing? Does it need replacing? Does it just need to go away? I’m not sure what will or should happen with WWDC, but I think there is a real danger here for Apple: Apple is successful because they work hard at doing what is best for their customers, which turns into good things for Apple. Continuing to please customers with better stuff than their competitors drives them forward. Developers are an important component of that success, even if they are not the driving force. A big part of what makes Apple’s products great is their consistency of purpose, style, and use. WWDC and other developer focused activities play a key part in helping third party apps maintain that consistency. Apple’s dilemma If developers are not regularly being immersed in the Apple way of doing things, will that produce a cultural shift that erodes that consistency? I’m sure Apple has some smart folks thinking about these things. I am hopeful that, just as with their products, they will find some new and innovative ways to solve it! Here is a little more information about me, Doug Sjoquist, and how I came to my current place in life. Hope you have a great day!

Renaissance IO 2013 Wrap Up
type: item
creator: dwsjoquist
date: 2013-01-24T15:50:05Z
subject: iOS Development
subject: Renaissance IO
subject: renaissanceio
description: Renaissance IO 2013 Wrap Up The paradox of choice There is a well organized and highly regarded developer conference each January in Ohio, CodeMash, that is in very high demand. They sold out over a thousand tickets in minutes, but I managed to get in quickly enough last fall to score a ticket. So by […]
encoded: Renaissance IO 2013 Wrap Up The paradox of choice There is a well organized and highly regarded developer conference each January in Ohio, CodeMash, that is in very high demand. They sold out over a thousand tickets in minutes, but I managed to get in quickly enough last fall to score a ticket. So by the time I started seeing tweets from Tim Burk and Bill Dudney about Renaissance IO, I was already committed to a late-January conference that looked very good. I’ve also been to several 360iDev and CocoaConf events over the last few years (you will find great value in either of them) and I plan on attending or speaking at each of them again this year. Each has it’s own style and I have benefitted from them both and look forward to being at each again. But, I was curious to see how Renaissance IO would fit into the iOS conference eco-system. Having heard Bill speak at conferences, I knew that if he was involved, the conference had great potential. And from what I knew about Tim, I thought they stood a great chance of pulling off something pretty cool. So, I decided to sell my CodeMash registration, sign up for Renaissance IO, and see. The tl;dr is that it was a great decision. Apples, oranges, and other fruity things This post is not an in-depth comparison of conferences, there is a great post over on Ray Wenderlich’s site that does that for several iOS conferences. But since Renaissance IO is new and couldn’t have been on the list, I thought I would share my thoughts while they are fresh. 360iDev mixes a great community with a good multi-track mix of sessions, providing great opportunities for starting new friendships and building on familiar ones. John & Nicole do a great job putting the 4 days together, and really foster an egalitarian feel between speakers and attendees. It has a family reunion (in a good sense!) feel to it. CocoaConf has a more concentrated multi-track schedule with the goal of delivering solid technical content at several different locations throu…

Cleanly Accessing the UITextView field in TWTweetComposeViewController
type: item
creator: dwsjoquist
date: 2012-06-04T10:00:32Z
subject: iDevBlogADay
subject: iOS Development
description: I have been working with my son Nathan over the last several months, helping him get started doing contract iOS development (check out his first solo app, Cincy Lineup.) While working on an enhancement, he needed to pre-populate the text of a tweet, then position the cursor at the beginning of the field with nothing […]
encoded: I have been working with my son Nathan over the last several months, helping him get started doing contract iOS development (check out his first solo app, Cincy Lineup.) While working on an enhancement, he needed to pre-populate the text of a tweet, then position the cursor at the beginning of the field with nothing selected to make it easy for users to customize the tweet. Apple’s TWTweetComposeViewController is a great component and takes care of most of the details to construct and send tweets for you, but it does not expose any of the fields. We could have looped through the views and subviews directly to find the field we want — but we wanted a safer method that didn’t depend on the current configuration of views, since that can change when iOS is updated. But, there is a simple, clean approach that does not try to find a particular view inside Apple’s view controller, nor does it depend on any private api’s or structure. We add a notification observer for UIKeyboardWillShowNotification, We call ‘presentModalViewController’ with our instance of TWTweetComposeViewController, When our notification handler method is called, we find the first responder, We check to see if it is a UITextView, We set the selection range to the beginning of the field so the cursor is prepositioned where we want it. … // at an appropriate place in your code, // add and remove the observer for UIKeyboardWillShowNotification [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(handleKeyboardWillShow:) name:UIKeyboardWillShowNotification object:nil]; … - (UIView *) findFirstResponderInView:(UIView*) view { if (view.isFirstResponder) { return view; } for (UIView *subview in view.subviews) { UIView *result = [self findFirstResponderInView:subview]; if (result) { return result; } } return nil; } - (void) handleKeyboardWillShow:(NSNotification *) notification; { UIView *fr = [self findFirstResponder:self.tweetSheetViewController.view]; if ([fr isKindOfClass:[UITextVie…

Introduction to Test Driven Development (TDD) for iOS apps (Part 2 of 4)
type: item
creator: dwsjoquist
date: 2011-11-07T20:08:26Z
subject: iDevBlogADay
subject: iOS Development
description: Introduction to Test Driven Development (TDD) for iOS apps (Part 2 of 4) Welcome back to the second part of the tutorial series, “Test Driven Development of iOS apps”. In part one of the series we introduced Test Driven Development (TDD), briefly discussed how it can help your development, and began the process using a […]
encoded: Introduction to Test Driven Development (TDD) for iOS apps (Part 2 of 4) Welcome back to the second part of the tutorial series, “Test Driven Development of iOS apps”. In part one of the series we introduced Test Driven Development (TDD), briefly discussed how it can help your development, and began the process using a simple Tic-Tac-Toe game as our app. In part two we will focus on how to think in a TDD fashion while we finish testing our model, the GameBoard class. In part three will will finish a stand-alone version of our game. In part four we will add some interaction with outside services to demonstrate how to use mock objects to help us test our code’s use of external services. We will pick up right where we left off in part one, but if you did not follow along part one with your own project, you can download the project file as of the end of part one. Our project already contains the GHUnit and OCMock libraries that we need for our tests, but if you would like help in setting up your own Xcode 4 project to use these libraries, check out the tutorial “Unit Testing in Xcode 4 Quick Start Guide”. Project Recap So far, we have: A little bit of upfront planning and design, A definition of “done” in the form of a small set of general requirements, A defined process to follow for adding to our app, Two simple tests, A list of things still to be done. In part one, we defined “done” for our Tic-Tac-Toe game as the ability: for a human player to enter their move; for a computer player to choose a move; to track the state of the game; to check whether moves are valid; to start the game; to know if someone wins; to know if the game is a draw. And finally, we stopped after writing only two pretty simple tests: testValidMove_row0_col0 testTwoValidMoves Remember, you will learn the most from this tutorial by following the steps and doing the work yourself, but if you get stuck, see the note at the end of the tutorial to see how to jump to specific points in the tutorial.1 …

Introduction to Test Driven Development (TDD) for iOS apps (Part 1 of 4)
type: item
creator: dwsjoquist
date: 2011-10-24T14:00:42Z
subject: iDevBlogADay
subject: iOS Development
description: Introduction to Test Driven Development (TDD) for iOS apps (Part 1 of 4) After a recent developer meetup, we were talking about useful things to do at future meetings. Someone fairly new to iOS development mentioned he would love to watch someone go through the design and development of an app. He knew he could […]
encoded: Introduction to Test Driven Development (TDD) for iOS apps (Part 1 of 4) After a recent developer meetup, we were talking about useful things to do at future meetings. Someone fairly new to iOS development mentioned he would love to watch someone go through the design and development of an app. He knew he could pick up many of the technical details himself, but he wanted a better understanding of the thought process and design decisions behind the development. As with any process that requires insight and creativity, that process and those decisions vary a great deal from person to person. Even if a particular process or development approach does not fit your style, you can still learn and improve by understanding different approaches. Test Driven Development (TDD) TDD is an approach to development that uses automated software tests to drive the design and development of an application iteratively. It pushes the developer to focus on one thing at a time, and usually one fairly small thing at that — but without killing the forest while tending to individual trees. One of the central practices of TDD is to write a test for some chunk of code before we write any code. The reasoning is that if we correctly express all of our expectations through our tests, when our tests pass, we know our application does what we want. So the success of our application is highly dependent not just on understanding the problem, but on how well we capture that understanding in our tests. We will explore TDD in this tutorial by developing a simple iPhone app that plays Tic-Tac-Toe. Because our focus is on TDD, we will spend most of our time learning how to think in a “test first” manner. Is TDD Really Worth The Effort? There are good developers out there that think TDD is not a useful approach so we need to try and separate the arguments against writing unit tests vs doing testing the TDD way. The arguments against unit testing in general are things like: I don’t have time to write double …

Writing Is Hard — Let’s Do Math
type: item
creator: dwsjoquist
date: 2011-10-11T03:00:28Z
subject: iDevBlogADay
description: Tutorials ‘R Us Several months ago, Ray Wenderlich put out a call for developers to write for his excellent tutorial site. So, I put my name in the hat, joined the team, and signed up to for my first tutorial in May: “Test Driven Development with iOS”. Part way through, we decided that it needed […]
encoded: Tutorials ‘R Us Several months ago, Ray Wenderlich put out a call for developers to write for his excellent tutorial site. So, I put my name in the hat, joined the team, and signed up to for my first tutorial in May: “Test Driven Development with iOS”. Part way through, we decided that it needed a separate, smaller tutorial on setting up the test environment first, so I wrote Unit Testing in Xcode 4 Quick Start Guide which was published in early June. Before very long, my small tutorial needed to grow into two parts. After working for a couple more weeks, it turned into a three-parter, and currently stands as a four-parter. After two months, it started to seem as though the more I wrote, the further the end was moving away. In the last month or so, I have finally started getting closer to the end as I write. But, given my current work load, it is very unclear when the end will come. Ray has been very gracious and patient, but we both decided it was not to be. Parts one and two are complete. Part three needs a final review, but is fundamentally complete. My plan now is to release the tutorial on my site as part of my iDevBlogADay posts, and hope that I can finish part four before it is time to publish it! So, stay tuned next time for “Introduction to Test Driven Development (TDD) for iOS apps — Part 1”. An Ode’ To Writing Tutorials Sung to the tune of “Beverly Hillbillies” (but not aloud please Come and listen to the story about a guy named Doug A poor blog writer, barely kept his blog feed up, Then one day he read his twitter stream, And there saw a plea for a writer team. Words that is, blog posts, steady stuff. Well the first thing you know Doug says I'll take that gig, It seems so cool, why not dig right in, How hard can it be to keep up with this and that, So he loaded up MarsEdit, and signed with R & V. Readers, that is, Analytics, Followers. ...much time passes (too much)... Well now its time to say good-bye to Ray and all his team. And I would like to thank h…

Live From 360iDev!
type: item
creator: dwsjoquist
date: 2011-09-13T02:00:25Z
subject: 360iDev
subject: iDevBlogADay
subject: iOS Development
description: Live From 360iDev! 360iDev 2011 is in full swing, and it’s been great so far. My OCMock Session On Sunday I gave an updated presentation/training session on OCMock Sunday morning entitled “OCMock: Crash Test Dummies For Your Code”. Overall, I was pleased with how it went. It was a three hour session, so we took […]
encoded: Live From 360iDev! 360iDev 2011 is in full swing, and it’s been great so far. My OCMock Session On Sunday I gave an updated presentation/training session on OCMock Sunday morning entitled “OCMock: Crash Test Dummies For Your Code”. Overall, I was pleased with how it went. It was a three hour session, so we took the first half to briefly discuss what mock objects were about, and then went through the fundamental features of OCMock using test cases to demonstrate each one. The demonstrations led to some good discussion with the group (about 40-50 devs) about testing in general, TDD, and OCMock. I was encouraged by the number of people that participated in the discussion, and I learned as much from it as the group did. After a break, we talked a little more about how to make good use of mock objects, and then I took the plunge into a live coding session, which is always a risk. To mitigate the risk I had scripted the entire sequence and practiced it several times. I used a simple text file with all the code blocks I needed so I could just talk, cut & paste, and demonstrate each step. Unfortunately, I chose to veer from the script early on (foolish!), made a simple mistake, and spent 10-15 minutes trying to clear it up. What I should have done was remove what I had just done and get back on script, but I ended up stumbling around and feeling foolish. Eventually, I came to my senses and just opened up the finished project to show what I had intended to do in the first place. Then I was able to mostly, but not completely, return to my script and finished the session a little better (but not great). Later that afternoon, I reopened the project I had built live during the session and fixed my dumb mistake in under 2 minutes. Oh well, hopefully I’ll remember to stick to the script next time, or approach things differently. Mingling With Other Developers One of the best things of a good conference is meeting new colleagues and renewing friendships with folks I haven’t seen si…

CocoaConf slides and project
type: item
creator: dwsjoquist
date: 2011-08-16T20:52:35Z
subject: CocoaConf
subject: iOS Development
description: CocoaConf in Columbus was a great conference packed into two full days. The shorter length made it easier to fit into my schedule, but the downside was the limited amount of time I had to talk with other developers. My talks on “TDD in the iOS World” went reasonably well. Better than I hoped in […]
encoded: CocoaConf in Columbus was a great conference packed into two full days. The shorter length made it easier to fit into my schedule, but the downside was the limited amount of time I had to talk with other developers. My talks on “TDD in the iOS World” went reasonably well. Better than I hoped in some ways, not as good as I wanted in others. Thanks to all who came, and took the time to write some comments! I got some good feedback from the the session evaluations. If I were to do it over again, among other things, I would: Be clearer about the session content, Shorten the overview of TDD, I think 10-15 minutes would have been a better fit for the audience, Do the code portion directly in Xcode, do more code examples live. btw, when you go to conferences, it is very helpful when you write comments about specific things, good or bad. General ratings are nice, but even a single specific comment is greatly appreciated. I did not upload my project files and slides to the CocoaConf site until Saturday evening, so they did not make it into the bundle (yet). I’m sure they will be available at http://www.CocoaConf.com soon, but for now, here they are: Slides part 1 Slides part 2 Project zip file that covers both sessions I am looking forward to seeing CocoaConf in Columbus next year. Thanks to all the Klein crew, speakers, and participants!