CocoaConf 2013 in San Jose

Last weekend I attended CocoaConf in San Jose.  CocoaConf is a technical conference for developers working iOS or Mac OS X.  Workshops and sessions are taught by form Apple developers and important developers in the industry, many of whom have written books.  It was a great conference, both for the content and for the opportunity to mingle with other like-minded individuals.

Resources

My Highlights

  • Beautiful and Shiny – The iOS Graphics System (all-day workshop) – The info is all available, but the workshop was a great forcing function to learn about it and try things out.
  • Unit Testing Your iOS App With Kiwi – Very interesting way to write unit tests. Built on top of the unit testing framework (OCUnit) that comes with an Xcode installation.
  • Cocoa Gesture Recognizers – Awesome flexibility.
  • Stronger, Better, Faster With Instruments And Debugging – Great introduction to using Instruments. One thing I didn’t know is that there are different instruments when you’re connected to the device and when you use the simulator.
  • Exploring MVC-N – My favorite session of the conference. The concept isn’t all that earth shattering – have a single component that is responsible for communicating over the network – but it’s one that we haven’t implemented to date that could simplify our network code.
    • The speaker is really down on 3rd party libraries because you’ve then delegated the knowledge of that area to a library you don’t know much about. Since networking is a core component of most apps, it should be something that is written in-house.
  • Cocoa Design Patterns – Presentation of using the Chain of Responsibility pattern to avoid singletons is very interesting.
  • NSPredicates for Fun and Profit – Very cool way to search through text and collections. Can make that logic very simple (or very complicated if you’re not careful).
  • Advanced Behavior and Performance Testing with UI Automation – Really interesting testing can be done with UIAutomation, but it’s all done in JavaScript and within Instruments.
    • Great list of tools provided in this talk.
  • Making Successful Apps – Good stuff for program and product management, although applicable for anyone designing and building apps.

My Detailed Notes

Beautiful and Shiny – The iOS Graphics System (all-day workshop)

Bill Dudney

  • The Layer of a UIView uses memory for every pixel
  • The frame property is now (iOS 6) a computed value.  Setting the frame sets the center and the bounds.size.
  • We shouldn’t be changing the frame on a view anymore as that messes up auto layout.
    • Note: We don’t currently use auto layout anywhere.
  • If you use the simple masks and shadows APIs, it uses offscreen rendering and is expensive.
    • Example: Rounded corners with clipsToBounds
    • Instead, use clipping masks.
    • Before you ship, always test with Debug -> Color Offscreen-Rendered in the Simulator to see what the app is doing.
  • You should avoid drawing unless you can build it in Photoshop, because drawing is expensive.
  • “Introduction to Geometric Modeling” video by professor at UC Davis who describes how Bezier curves work.
  • Don’t implement gesture handling using touchesBegan and touchesEnded.  Instead, use a gesture recognizer.

Mastering The Project File

Michele Titolo

  • Slides
  • Apparently project.pbxproj files can be converted to JSON, although I couldn’t get it to work.
    • plutil -convert json project.pbxproj

Unit Testing Your iOS App With Kiwi

Pete Hodgson

  • Slides
  • Kiwi is built on top of SenText (OCUnit) using blocks and syntax that looks vaguely like English.
  • Kiwi can handle stubbing and mocking, although he didn’t include any details in his talk.
  • It is recommended that we use CocoaPods to pull in 3rd party software.
  • “Test what you can isolate.”

Keynote:  The People We Work For

Matt Drance

  • Customers
    • Think about how what you are doing (designing, implementing a feature, fixing a bug) will make their lives better.
  • Peers
    • Communication is important in helping the team be productive.  This could be as simple as sending an email to let people know where you left off if you are going on vacation, moving to a different project or group, or leaving.   “Reduce tension in the room.”
  • You
    • Make sure you take care of yourself.
  • Tools

Cocoa Gesture Recognizers

Jonathan Penn

Stronger, Better, Faster With Instruments And Debugging

Kyle Richter

  • Slides
  • This was a fairly basic overview of the debugger and Instruments, but very useful.
  • Breakpoints:
    • Conditional breakpoints appear to be pretty performant.
  • Debugger command line:
    • The list command will list the source code around the current breakpoint.
    • The bt command will list the backtrace for the current break.
  • “Make sure you test against slower devices, such as the 3GS or the 4.”
  • There are different instruments for running on a device and running on the simulator.
  • Leaks that are the same size but aren’t grouped together may be the same leak but for some reason Instruments didn’t group them together.  This is similar to behavior we see in BugSense when grouping crashes together.
  • Other tools:
    • Network Link Conditioner.
    • Blended Layers in the Simulator
      • Using a clear background color requires iOS to composite the view with the background which is expensive.  Avoid clear background unless you can’t determine the background color.
    • Misaligned Images in the Simulator
      • Misaligned images will be slightly blurry.  Normally caused by math errors when laying out views.
    • Slow Animations in the Simulator

Exploring MVC-N

Marcus Zarra

  • Slides
  • If you’re using other people’s code (e.g. a 3rd party framework) you’re probably doing the wrong thing.  Why?  Because you consider this a solved problem but you didn’t write the code and therefore likely don’t understand what that 10,000 lines of code are doing.
  • The concept of MVC-N is that networking is separated out from the view controllers.
  • The NetworkController talks to the network and stores the result in the persistent store – Marcus uses Core Data.
    • Properties:
      • NSOperationQueue
      • NSMnagedObjectContext
    • Method
      • Different method for each type of request
    • How to create
      • Dependency injection
      • Singleton
      • AppDelegate property
  • Have one NSOperation subclass for each network call.
    • He doesn’t recommend using blocks because blocks are not easily cancelable.
    • Another problem with blocks is because of code bloat – a lot of code in one place.
  • For unit testing, he recommends setting up a simple server on the local network that always returns the same result.
  • If you can let network operation fail without notifying the user, do it.
  • Summary
    • Own your network code.
    • Don’t put network code in view controllers.
    • Keep all network code together.
    • All UI should feed from Core Data.
    • Disconnect data collection and data display.
  • http://github.com/zarrastudios
  • Questions:
    • I asked him about using Core Data for data we don’t need to persist (e.g. most of our data) and he recommended it using an in-memory store.
    • NSManagedObjectContext can be used to represent data received from the network, which represents the data as key-value pairs.

Cocoa Design Patterns

Saul Mora

  • You don’t want to release crapps.  You want to release apps.
  • Patterns
    • Chain of Responsibility pattern, aka Responder Chain
      • Call sendAction:to:from:forEvent: to make a request of an object in the hierarchy.
        • Example: Dismissing the keyboard can be done by calling this method on the application object and specifying self for the “from” property.
      • Derive the app delegate from UIResponder.
    • Command pattern
      • We do this with our operations by creating a separate object for each network operation.
    • Template pattern
  • Anti-Patterns
    • Factory, Abstract Factory
    • Singletons
      • Consider a Singleton Manager – Service Locator pattern.

NSPredicates for Fun and Profit

Josh Smith

  • Slides
  • You can use it for scanning strings, arrays, and Core Data.
  • Predicates are basically search expressions which can be strings (BEGINSWITH, ENDSWITH, CONTAINS, etc.) or a block.

Advanced Behavior and Performance Testing with UI Automation

Jonathan Penn

  • Slides and sample code
  • UIAutomation is all in JavaScript in Instruments.
  • It is completely sandboxed so you can’t use NodeJS or other frameworks.
  • You can see screenshots within Instruments as your script runs.
  • You can use the accessibilityIdentifier to display various states in Instruments as you change the state.
  • He recommends including “use strict” at the top of the script.
  • Define tests in a function in the script.  Doing this puts all messages displayed by the script on a single line that can be expanded.  This also sets a log type (e.g. Pass or Fail) and shows a different color on the timeline.
    • He showed raw JavaScript, which was very messy.
    • Then he showed functionalizing the JavaScript so that the tests looked like single statements.  Much cleaner.
  • He showed swiping up and then down repeatedly in a loop to find a memory leak.  Very cool!
  • Tools:
    • Reflector – AirPlay iOS device screen to your Mac
    • UI Screen Shooter – Take screen shots of your app for the app store
    • tuneup.js – Collection of JavaScript utilities that build upon and improve UIAutomation
    • mechanic.js – Lets you take the power of UIAutomation with the simplicity of modern JavaScript CSS selector engines to make your UIAutomation scripts terse and beautiful
    • Bwoken – iOS UIAutomation  test runner runs UIAutomation tests from the command line in the simulator or on the device
    • cisimple – Continuous integration in the cloud
    • Book: Test iOS Apps with UI Automation
    • UIAutoMonkey
    • KIF (Keep It Functional) – iOS integration testing framework

Making Successful Apps

Michael Simmons

  • Co-owner of Flexibits who created Fantastical which was at one point the top app in the App Store.  He also owns the company that does HockeyApp.
  • Why are you *really* doing this?
  • What are your goals?
    • > You cannot be on autopilot.  You have to question everything.  Otherwise, how do you know that what you are doing is right?
    • > (If the UI is good (easy to use, simple, etc.) it will be successful.)
    • Why are you doing this?
    • What do you want?
    • Dream but be realistic!
      • Don’t be afraid to ship your 1.0 with limited features, but communicate with your users what your plans are to provide those features.
  • What is your plan?
    • Too ambitious?  Not enough?  Real artists ship.
  • Who is your audience?
    • Consumers?  Professionals?  Both?
      • How can it be for both?  It can start out simple and then build up as the user uses it.
    • Creating an appropriate app is vital.
  • What is your passion?
    • What excites you?
    • What makes you happy?
    • What underwhelms you?
  • Details you should be thinking about
    • Be the best.
    • Are you doing something unique and original?
    • Marketing is not an evil word.  If you build it, they might come.  Marketing doesn’t have to be sleazy.  It is required to build awareness.
      • Marketing is also about the design of the app and of the icon.
      • They use the Icon Factory for their icons.
  • App Launch
    • Sneak peek/teaser (public beta?).  Create mystique.
    • Last minute details dialed in.
      • For sales, they use Fast Spring for selling from their website as well as selling through the App Store.  This also allows them to offer a free trial.
      • You can create promo codes to make your app available to press or others before you release.
    • Marketing/PR
      • Embargoes are tricky.  He doesn’t use them anymore because when you release through the App Store you don’t have any control on when it is actually available.
    • Launch!
      • You should do your own support because it is the lifeline to your customers.
      • Negative emails are fantastic because your users are passionate about your app.
      • Don’t rely on your users to design your app.
      • 99 cents is not the right price for app.  Is a a marketing tool.  If your app is that good it will sell.
  • So, how do you make great apps?
    • Define your goals.
    • Create a plan.  Or two.
    • Find your passion.
    • Admit your weaknesses.
  • Piwik (http://piwik.org/) – Web analytics.
  • Frequency of updates
    • You want to get an update out at least every 3 months.
    • Don’t update for the sake of updates.
  • 3rd party support (e.g. Get Satisfaction)
    • He doesn’t like them as it gets between you and your users.
    • He hates forums.
    • He prefers email support.
    • He has a policy of responding within 24 hours.  Users love it.
  • Release notes
    • If just “Bug Fixes” include the release notes for the previous version as well.
  • Keywords
    • Don’t use competitor names as keywords.
    • The obvious ones are the important ones.