Friday, 9 September 2011

iOSDev UK: The Eternal Sunshine of the Developer Mind

Steve “Scotty” Scott, iDeveloper iDTV, @macdevnet

Scotty gave a great talk complete with loads of cartoons that I can’t remember here. I’ve just noted down the more serious bits…

However, the best slide was by far:

Pocket Dan - from @macdevnet's presentation at iOS Dev UK 2011

  • programming is:
    • 10% science
    • 20% ingenuity
    • 70% getting the two to work together
  • embrace your pain and draw positives from it
  • just because something has failed, doesn’t make you a failure
  • unless you can own the failure, you can’t understand the problem and move on
  • if you’re trying to learn what went wrong, make sure you’re looking at the real issues
    • keep on asking why until you hit the real reason
    • was it the people or the technology?
  • you don’t have time not to do this
  • when you next find a situation that’s negative, find a positive
  • make sure you learn to understand what people are saying, rather than what you are hearing
    • “developers get confused between Xmas & Halloween because DEC 25 = OCT 31”
  • it is impossible to mentor yourself
    • you can’t get out of your own assumptions
    • you don’t need someone highly experienced to mentor you — you just have to explain yourself and get someone to ask, “how do you know that’s true?”
  • often our thinking is shaped by a whole load of things that you haven’t let go
    • process it and let it go
  • we don’t tend to learn a lot from success
    • that’s ok - we just need to do the same thing again

iOSDev UK: Design Considerations for Educational Apps

Fraser Speirs, Head of Computing & IT, Cedars School of Excellence, @fraserspeirs

http://speirs.org

  • last year gave every child an iPad
    • only 100 pupils
    • had 220 people come to visit the school…
  • when you give people the internet the whole time, you sometimes get unexpected results
    • Fraser showed a slide of coursework on cell nuclei, decorated with a background showing the Statue of Darth Liberty
  • sitting around iPads — everybody faces each other rather than all facing the screen at the front
  • avoiding the ceremonial computer lab — moving to casual computing
  • beautiful artwork created by kids on iPads, within a month of receiving them
  • it’s not just the iPads, it’s the 1:1 — the 1:1 is more important
  • Fraser’s daughter is 4.5 — just started school
    • will graduate from university in Summer 2029
    • “we are already teaching the citizens of the 22nd century”
  • looking at investment as kids’ chairs & tables
    • not as a guarantee that scores will go up

Do’s and Don’ts for apps in schools

  • don’t assume the internet works correctly
    • schools change what internet is available through frequent policy changes
    • youtube is often turned off
  • teaching fashions come and go regularly
  • in-app purchase doesn’t work in schools
    • central purchasing or gifting
    • e.g. PCalc has a full version that can be purchased at once
  • don’t assume your users can (will) read
    • use conventions wisely (keep the back button in top left corner)
  • use push notifications sparingly
    • no good advertising to kids in school — they don’t have the app store password anyway
  • watch out for number of devices nearby
    • could be 20-30 devices around
    • infrastructure may cope, but leave room in your UI
  • limit or prevent app store interactions
    • no good in schools
    • confuses kids; annoying for teachers
    • that goes for “review me now” too
  • teachers need access to content
    • support the photos app
  • don’t promote facebook
    • facebook can be a major source of anxiety for many children
  • watch out for shaking gestures — not good for
  • don’t use bad language (and try to avoid double-entendres and local slang too). Some examples:
  • be very careful with user data — especially with location
  • talk to teachers and test with actual children
    • Fraser’s school does not have the scale to be a beta tester…
  • watch out for different curricula in different countries
  • walk through guide in the app
  • kids can use loads of apps to edit graphics, passing the image through the photos app
  • use sharing effectively
    • use “Open In…”
    • avoid huge sharing option lists
  • show proof of completion
  • avoid (penalise) random hits
  • structure + headroom = creativity
    • app idea: make toontastic for creative writing
  • show user activity
    • e.g. Brushes lets you record all your strokes and play them back as a quicktime video
  • localisation is useful even if your app is UK-specific
    • e.g. Iraqi boy with a 1:1 iPod touch switched it to Farsi and used Google Image Search to show pictures of what he wanted to the teacher
  • support projectors & AirPlay
    • don’t offer resolutions for external display — just pick one and do it well
  • there is a control to turn off Game Center at a policy level
    • so go ahead and put it in the app but make the rest of the app work without it
  • gap in the middle for 7-10 year olds
    • need more apps like toontastic — structure provided, but space for creation
    • older kids can use general content apps
    • younger kids don’t need so much freedom
    • using iThoughts HD for mindmap, then writing in Pages

example apps

Q&A

  • research?
    • study with university of western scotland
    • two lessons back to back: one with iPad, one with paper & pencil
    • same teacher, same children
    • with paper & pencil, boys and some girls had less emotional engagement
    • with iPad emotional engagement of all pupils was brought up to same level as best kids
    • being submitted to BJET, but may not be published yet
  • separate educational version of an app?
    • kids want the real thing
    • universal design is best
    • Fraser tries to buy things off the shelf rather than waiting for educational specific versions
  • damages?
    • only had one — parent ran it over with Land Cruiser!
    • kids are careful — the iPad has their name on it
  • teachers adapting to technology?
    • about half of the teachers had iPhones/iPod Touches before the programme started
    • the iPad is significantly more approachable than other computers
  • how do you find apps?
    • school subscribes to Tap! magazine…
    • more popular than the TES :-)

iOSDev UK: Standing Out from the Crowd

Craig Lockwood, HuwDavid, @craiginwales

  • put a QR code on the presentation screen for a voting web page
  • pre-render your icon so you have control of the gloss
  • localisation
    • french, dutch, german, italian translations pay dividends
  • app microsite
  • using social media
    • shout loudly yourself
    • and get your users to shout louder
    • “if you’re not ethical, at least be targeted”
  • make your app meta data relevant
  • watch out for the app size
    • you can’t download an app > 20Mb over 3G
    • you have one opportunity to sell — don’t waste it
  • niche press works well for niche products
    • e.g. rare pig breeds app (Guide to Pig Keeping), got featured in Farmers Weekly and got 6,000 downloads in a short period
  • getting designers:
    • there are plenty of media students who are looking for portfolio work…

Q&A

  • how to deal with app store feedback complaints?
    • point to the app website & twitter account within the app
    • people look at the reviews more as the cost goes up (even if it’s only to £2.99)
    • get your friends and family to review when you release — get in first with 5 star reviews
    • good screenshots can filter out people who don’t understand the app
    • price tier 2 gets less scathing reviews than tier 1 & free

iOSDev UK: Designing multi-user, single device interfaces on the iPad

Kate Ho, interface3, @kateho

  • Started by designing for Microsoft Tablet
    • kids started saying “this would be really cool an iPad…”

Example multi-user apps

Multi-user (sharing a single device at the same time)

  • Versus Games:
    • Examples: PaddleBattle, Dorfball(?), Table Twister, Touch of Fun
    • Very simple games: you’d think people would get bored, but people get very competitive
    • “You can only play for 30 seconds at a time without killing each other” — playing with 8 year-olds can be very bad
    • Best place to find inspiration for these games are the Wii mini games (Raving Rabbids, etc)
  • Co-op Games:
    • Complete an objective together
    • from interface3: iHave (just released)
    • who has the maths answer?
    • collectively get as many points as possible
    • SliceHD — maybe not meant for multiplayer, but great for kids!
  • Games with a twist:
    • one idea: two people playing on an iPad, and another player on a
  • Creative
  • Exploration scenarios
    • Topsee — can have a look at something and pass it over to someone else
    • interface3 interactive mortgage guide on a Surface
    • multitouch is better than keyboard since you don’t have to ask permission from the other person — just reach in a grab
  • Small group interactions
    • one person in charge and two to three people learning over the same device
    • interface3 built CoachAssist

Tips

  • design without orientation
    • circular buttons with both-way-up text
    • rotate the text every now and then
    • draggable, rotatable objects
  • try to avoid one player’s actions getting in the way of others
  • design for short interactions
    • around an iPad people are sharing personal space
    • especially if they have to put their head over the screen
  • make sure players aren’t kept waiting
  • don’t have too many complex gestures
    • “gestures are like the 21st Century command line”
    • you shouldn’t spend too much time explaining yourself
  • create shared experiences
    • what could two people do together that they couldn’t do by themselves

iOS Dev UK: Your App Sounds Great

Dave Addey, Agant Ltd, @daveaddey

This was one of the barcamp slots in the evening. Dave went through the presentation he gave previously at NSConference on VoiceOver, Apple's device support for blind and partially sighted users.

  • RNIB have an accessible app of the month
    • they’re really interested in helping people
  • 2m blind or partially sighted people in the UK
    • equivalent to population of Birmingham, or lefties, or gingers!
  • How it works:
    • label - description
    • hint - results of interaction
    • traits - only need if making a custom control
  • triple tap with voiceover enabled to turn screen curtain on — blacks out the screen so you can test it without cheating
  • use UIAccessibilityPostNotification(UIAccessibilityNotification, ...) to post sounds on events rather than touches
  • iOS knows quite a lot of UK place names, but not all (and especially not Welsh names)
  • can set your own usability tags, but uses normal spelling, not phonetic characters
    • can use say "word" on a Mac to test
  • can define accessibility containers to group stuff
  • it’s not just about making it accessible for a blind user or a partially sighted user, it’s also about making it usable for a sighted and non-sighted person using the app at the same time
  • At the bottom of accessibility options there’s a triple click home option — you can make this toggle VoiceOver
  • Maps do not have accessibility other than the pins
  • If stuff is still being selected by VoiceOver, then you might need to set them to be disabled

Thursday, 8 September 2011

iOSDev UK: Robots!!

Mark Neal, Co-ordinator for the Intelligent Robotics Research Group, Aberystwyth University

  • learning & adaptation
    • neuro-endocrine control
  • visual navigation
    • robots with cameras on top finding out where they are and how they are standing
    • gyroscopes etc don’t always work in harsh environments
    • map-building
  • control systems
    • trying to make things that are redundant and reconfigurable by themselves
  • try to get out of the lab!
    • sensors may start giving you junk…
    • ideally having stuff work over a few years
    • watch out for “Dalek syndrome” — falling down stairs
    • flexibility tends to be reversible, adaptation tends not
  • department suffers from too much kit and not enough people
    • started in 1998/99
    • now have about 10 wheeled robots
    • 2 and 4 wheel pioneers — not enough ground clearance so best indoors
    • have had balloons and kits
    • now have quadracopters…
    • also have sailing robots
  • robot: autonomous
    • try to avoid remote control other than start/stop
  • would like to buy off the shelf and build software
    • works for little indoor bots
    • but bigger ones don’t really work outside
    • better to build yourself, or at least adapt
  • pioneer
    • linux box on wheels
    • 16 sonars
    • laser scanners and grass don’t mix…
  • iCub — fancy toy
    • human-shaped but can’t walk
    • investigating how kids learn to do hand-eye coordination
  • IDRIS
    • weighs 400kg
    • 4 landrover sized tyres
    • have done lots of work laser scanning monuments
  • ARGO
    • 6-wheel drive amphibious
    • £10K and then convert with a few more £K to make an autonomous robot
    • doing the same with GWiz electric cars
    • ARGO planned to be used as a radar tug in Greenland
    • power is the killer
  • aerial robots
    • had three helium balloons navigating in formation
    • kite with aerial photographing — software is to stabilise the image based only on the camera
  • sailing robots: Beagle B
    • 3.6m long
    • disabled sailor’s boat
    • vertical aerofoil wing on top instead of a sail
    • has to be autonomous since the Wi-Fi only extends about 30m
    • control system designed to use as little rudder and ropes as possible
    • almost no power to run: < 5W
    • 6W from solar panels
    • unusual to have an autonomous robot that lasts more than a few hours
    • these last at least 49 hours!

iOSDev UK: Making Money with In-App Purchases

Dave Verwer, shinydevelopment, @daveverwer

Developing in-app purchases in the Explore Flickr app

  • purchases can be:
    • content, functionality (permanent purchases)
    • services, subscriptions (repeatable purchases)
  • have to design your own store
  • in-app purchases restrictions:
    • no promo codes or volume purchases
  • store should answer:
    • what is this store?
    • what will I get if I upgrade?
    • big green friendly buy button
  • ruby script to switch info plist based on DEBUG/RELEASE — needed to switch between versions
  • measure success with analytics
    • log each stage to capture where people fall out
    • e.g. store shown, video played, upgrade button tapped, upgrade process complete
  • 1.6% conversion from Explore Flickr (from those who view the store)
  • A/B testing for store designs
    • HuffPost do A/B testing on headlines
    • have 3 choices for first hour, then automatically chosen
    • be consistent with presentation (don’t let people know we’re A/B testing them)
    • need to know if we’re still A/B testing
    • put both bits of code in app, and choose according to web check on first launch
  • Results:
    • store -> video -> upgrade pressed -> upgraded
    • A: 100% -> 7.5% -> 3.2% -> 1.6%
    • B: 100% -> 9.5% -> 3.5% -> 1.8%
    • interesting stat is that video
  • What next?
    • make the store more dynamic
    • downloaded plist file for wording
    • HTML for whole store page (but would need to download and cache it)

iOSDev UK: Mobile Apps: Bringing Together Real and Online Worlds

Graeme Gibson, AppSherpas

  • iOS device as controller
    • an interface to home automation using DMX
  • existing products:
    • POSCard: point of sale mobile commerce at low cost
    • Print&Post: Royal Mail from an iPhone
  • use eye movements to control a device
  • mobile image discovery
    • scan an image instead of a QR code
    • extracts “DNA” of image
    • matches against database of monochrome images
    • 3-5s response on 3G (< 1s on Wi-Fi)
    • 100% accuracy for flat objects with a reasonable amount of light, that are large enough in the phot
    • 70-80% accuracy with less light and > 15% perspective
    • unlike QR codes, works for distant media (e.g. poster on the other side of the road)
    • also works for a trailer on the TV
  • indoor wifi location is already available with Cisco kit
    • no extra client kit
    • extra stuff needed in the AP

iOSDev UK: Coding for your Future Self

Martin Pilkington, @pilky

  • there are three you’s
    • now — doing the work
    • future — code guru
    • past — got let near your computer and vomited all over your code…
  • consistent formatting — follow conventions
    • don’t fight the conventions
  • composition vs subclassing
    • cocoa often better to use composition
  • copy immutable classes — don’t use a reference
  • don’t ship code with exceptions
    • in Objective-C they’re for invalid state — programming errors
    • use NSError instead
  • naming
    • don’t abbreviate
    • no namespaces, so prefix all your classes, preferably with 3+ chars
    • prefix category methods on other classes too, e.g. abc_categoryMethod
    • capitalise acronyms
    • if last param is error return, should be error:
  • if you comment every method then you’ll be in the habit of commenting when it counts
    • not sure I totally agree — comments can get out of date with the code. perhaps better to comment longer code pieces rather than each and every method
  • large classes and large methods are unmaintainable
    • also splits out more stuff into back-end code
    • better for testing, better for multi-platform
  • better to inject dependencies (tell, don’t ask)
    • or at least expose a property to set during tests
    • if do so, then either set default in init, or use lazy construction in the getter method
  • notifications
    • can also be distributed to other devices
    • see kellabyte.com for continuous client
  • regular refactoring:
    • always leave the campground cleaner than you found it
    • have spring cleaning days/hours
    • lots of little refactors mean less big rewrites!

iOSDev UK: Adapting Content for Apps

Dave Addey & Alyson Fielding, Agant Ltd, @daveaddey & @alysonf

  • Why an app?
    • Can you do something with it in dead time?
    • It’s always there when you need it
    • Would you use it yourself?
  • Preparing content
    • content definition lets you split up content into small pieces
  • iPhone vs iPad
    • use cases are different
    • e.g. full page illustrations just don’t work on an iPhone — universal app just doesn’t show them
  • network content:
    • assume no network and make as many things possible as you can
    • then download & cache what you need when network becomes available
    • same goes for submitting stuff — add it to a queue and submit it when a network becomes available
    • e.g. QI app submit a fact
    • provide the app bundle with some initial content to get started
    • if you have information always show it — but show how old it is

content formats

  • HTML
  • Property list
  • Custom XML
  • NSAttributedString
  • Core Data store
  • SQLite database
  • bundled media files
  • text files — e.g. QI facts to rate
  • PDF
  • e.g. QI app
    • books came as ePub (HTML)
    • needed tidying, but was very useful
    • errors could be spotted & fixed directly
    • however, not the right format to put in the app
    • used script to transfer into NSAttributedString
    • better presentation
    • better layout for images & text
    • better pagination
    • content definition really helped
  • e.g. Malcolm Tucker
    • email views driven from plist
    • Aly edited directly in XCode and rebuild to check
    • email content in HTML
    • attachments in PDF
  • e.g. Arsenal app
    • already had a CMS for the website
    • beginning of project — defined an API
    • tweaked the API throughout development, but had something to work from right at the beginning

Helping content experts

  • work hand in hand with them from the beginning
  • make sure they have a real device that they’re using every day
  • try to let the content expert able to make their own build of the app as they change the content
    • anyone working on the content has XCode installed and knows how to build it
    • they also have access to check stuff back in
  • let them play with your toys — it’s fun!
  • put the content in with the development

stats

  • 2.7 million stations are picked from UK Trains picker every month (~88k per day)

Q&A

  • testing
    • looking to do more
    • UI testing is a bit of a faff, but is possible

iOSDev UK: Tap to Experiment

Chris Ross, Osmosis Apps, @darkrock

An attempt to find success on the AppStore

  • App: Tap to Chat
    • Other chat apps look very similar — buddy lists & tab bars
    • Decided to try something different — picture-based
  • Go along to a nearby group (e.g. Brighton iPhone Creators)
  • Experiment #1: universal Facebook chat app with a novel UI
    • 1.5 weeks each for two people
    • Used pre-existing code from other apps (Facebook XMPP chat)
  • Collaboration helps — both to evolve good ideas and filter bad ideas
  • Can appeal app store rejections, even if you don’t change the code (e.g. if your app relies on a third party that was down during testing)
  • Don’t underestimate the phenomenal power of the Christmas period
    • e.g. EA drop their prices just before Xmas, their apps go to the top, and their downloads rocket
  • Experiment #1.5:
    • iAds seeing only 10-15% fill rate
    • Apple pay you just to show the advert
    • Admob have a higher fill rate, but only pay you for click-through
    • More differentiation with paid app
    • Removing adverts is not enough to get people to buy the paid version
    • Added “share app on friends’ walls”
    • had a spike -> 1000 shares a day
    • revenue jumped to £4-4.5K / month
  • Experiment #2:
    • Started a company to house the app
    • Rewrite the code
    • Changed the facebook (spamming)sharing since Facebook complained…
    • but they were polite
    • Added Google chat, AIM + others
    • More free apps: one per API — better upgrade path (get all in one app)
    • Got a designer
  • Aimed to do all that in two weeks…
    • but took three weeks from 6am-11pm
    • downloadDidFailWithError is a private API
  • Got an expedited AppStore review to be in store in time for Apple Design Awards
  • Results:
    • Revenue jumped to c.£6k/month
    • Difficult to convert people from v1 to v2 (especially since v2 was on a new (company) iTunes account)
  • Success in the AppStore?
    • Overall stats:
    • Mean amount of money made: £30,000
    • Median amount made: £600
    • Tap to Chat:
    • 18% revenue from paid apps (18K downloads)
    • 82% revenue from adverts in free (500K downloads)
    • £40K made so far
  • Moving to using mopub to do advertising
    • provides more control on the server side
  • Mistakes
    • changed sharing in v2 — less visibility
    • no push notifications in v2 (but kind of a choice anyway)
    • transitioning to a new iTunes Connect account
  • Next steps
    • building a backend server for push notifications
    • building libraries for MSN & AIM
    • improving user retention:
    • Osmo character offers advice and news

Q&A

  • Facebook App ID
    • can share same app ID between apps
    • v1 & v2 (different iTunes Accounts) and free apps use same facebook app ID
  • Facebook spamming guidelines
    • you must have a single action per share
    • you must allow the user to edit their text on others’ walls
    • If there is an issue, facebook contact you to say that you have to resolve the issue in 24hrs — but they need you to respond in that time
    • you can ask for a grace period
    • Tap to Chat asked for 2 weeks
  • Transferring iTunes Accounts
    • can convert a personal account into a corporate account if you ask
  • Experiments with price?
    • v1: 59p
    • aim to bump the price with each added network
    • “no point putting things for less than £2 on the app store — if people have made a decision to buy it, then they’ll buy it…”

iOSDev UK: Handling the Press

Chris Phin, Editor, Tap! Magazine, @chrisphin

Or, “How to get five-star reviews, sell millions of apps, and retire six months from now — guaranteed!”

  • Getting an app noticed:
    • Exposure
    • Endorsement
    • Tap! magazine really want to embrace developers
    • Purchase
    • 91% of readers buy recommended apps
  • UK magazines make money from selling issues
    • In the US it’s more based on advertising
  • How reviews are chosen?
    • Gut feeling from the editors
    • Fitting in to specific sections
  • How to piss off an editor?
    • Not knowing the magazine title or anything about it…
    • Unfocussed pitching
    • Aggressiveness
    • Choosing the wrong comms channel (email/SMS/phone)
  • How to make an editor happy?
    • Devs with passion & high standards
    • Personal connection — trust other devs’ feelings
  • Freelancers
    • e.g. Craig Gennell — Tap! mag contributing editor for games
    • Some are integral part of team; some are chancers…
    • But help them as much as possible
  • Press releases
    • Same rules as any other content — first line should be who made the app, its name and what does it do
    • Links — to the web site and the app store
    • Contact details
    • include twitter
    • After all this, can put in description of company (but not before)
  • Website
    • What it is — in as few words as possible
    • Price — including details of promotions (if poss)
    • Screenshots — equinux.com does a good media room
    • Contact details — again, specific media details if poss
    • Contact forms not so good as the sender can’t track the outgoing email
    • So have an obfuscated email address on the page
    • Reviewers’ guide
    • Often hooked around a narrative
    • Opportunity to guide the review — pick out USPs, etc
  • What to do when you get a review
    • Read it! Not just the score…
    • Take any feedback
    • app reviewers see a lot of apps, so maybe a little more informed
    • but they are just another individual user!
    • Shout about good reviews
  • Other ways to get in a magazine
    • Not just full reviews: app roundups, features, updates
    • Building relationships leads to tweets etc

Q&A

  • innovative ways of catching attention
    • direct mail involving cookies!
  • press area
    • often include reviews from other magazines (but that’s not useful for reviewers)
    • screenshots, hi-res logos, videos
    • useful to have a zip
  • beta builds
    • interesting from bigger apps (well-known, anticipated)
    • Chris loves TestFlight
  • mailing out
    • really targeted, passionate, individualized approach to 5 or so key targets
    • mailshot out the rest
  • screencasts?
    • prefer image galleries as can skim them
    • otherwise, 20 seconds max!

iOSDev UK: iPad-native Game Design: Exploring a New Gaming Interface

Gareth Jenkins, @36peas

  • iPad specific — using the iPad interface as primary interface to game mechanic
  • Multi-touch interfaces don’t work when you can’t see what you’re interfacing with
  • The iPad is more likely a shared device
  • iPad player more likely on the sofa than the toilet :-)
    • i.e. usage is more purposeful rather than filling time
  • areas of focus:
    • take advantage of space available
    • think about appropriate gestures
    • think about gaming context
    • think outside the (phone) box
    • iPad specific does not mean exclusively iPad — take the idea elsewhere as well
  • examples:
  • iPad provides more room for dedicated interaction areas
    • e.g. left hand & right hand controls on edges + general interaction in middle
  • ways to think about it
    • play lots of iPad games
    • play iPhone games scaled up and work out what’s wrong
    • look at the fingerprints on your device!

iOSDev UK: Animation for Serious Apps

Neil Taylor, Aberystwyth University, @digidol

  • CALayer is not actually the view — it’s the model
  • Old-style UIView animations are now discouraged — start to use blocks instead
    • block-style also allows you to add further animations on completion
  • CALayer animation is slightly different
    • animate position, not centre
    • bounds, not frame
    • values are animated, not changed
    • CAAnimation setFromValue:/setToValue:
  • Keyframe animation lets you animate across a complex path
    • Core Animation will calculate intermediate frames
    • e.g. shopping cart items thrown into a cart at the bottom of the screen
  • Other bits
    • can have transactions to tie animations together
  • More useful references in slides…

iOSDev UK: Real-World Data (or There and Back Again)

Hamish Allan, Olive Toast

The story of writing Files Pro — an app to take files with you on an iOS device.

  • Used Deusty’s CocoaHTTPServer
  • Dropbox has a nice API
    • operations are aynchronous
  • Gamekit makes device to device connection over bluetooth easy
  • Could use HTML5 to make a PC-based interface to an iOS app
    • Visit a web page served from the device from your PC and see a flexible app within your browser
  • iCloud
    • NSFilePresenter tells you when a file transfer has completed
    • iCloud syncs the meta-data about files first, using NSMetadataQuery
  • “Your market is not power users”
  • Apple is moving towards a flat list of files with search, rather than a hierarchical system

Q&A

  • No hooks in iOS for AirDrop (yet?)
  • Nor any GameKit APIs which talk to desktop

Wednesday, 7 September 2011

iOSDev UK: Using TDD to write an iOS App

Graham Lee, professional in-betweener, @iamleeg

Or, “What is TDD and why should you use it?”

  • discovering bugs is not the point of testing at all
    • instead, you are proving that there aren’t bugs
  • once we’ve fixed bugs, we don’t want to see them ever again
    • tests can ensure that regressions don’t come back
  • TDD allows us to prevent bugs from ever happening!
    • you won’t prove that the app works how the customer expects, but you will at least prove that it works how you expect it to work…
  • TDD imposes black-box thinking for the developer
    • makes you think about how the code should be designed and scoped
  • accurate planning: we know how much we’ve done
    • and we can be honest how much we have done
  • TDD does not:
    • ensure that the developer understood the requirements!
    • ensure that the requirements remain static
    • ensure that pieces work together (unless you add integration tests)
  • tests should be short and have descriptive, English names
    • e.g. testDatesOnTheSameDayAreConsideredSame
    • general pattern
  • tests should be fast — well under a hundredth of a second each, so a second or so for all of them
    • avoid integration tests in unit testing since they take too long
    • don’t interrupt your concentration by waiting for tests
  • as a result, your classes will be smaller and have obvious effects
    • any side-effects are few and easy to predict
    • if your test fixture gets big, then that’s a sign that you need to refactor (possibly including the tests!)
  • TDD encourages “tell, don’t ask” configuration
    • inversion of control
    • pass in helper data rather than discover it internally
  • avoiding testing everything at once:
    • use fake objects (with same interfaces) to provide simulated interactions
    • use mock objects to record and verify interactions
  • Objective-C mock frameworks:
  • Code coverage is useful for adding tests to an existing app
    • Not so useful for building new code
    • If you’re not covering code with TDD, then you’re kind of cheating yourself

Q&A

  • @pilky knows about using the accessibility framework to write automated UI tests using javascript
  • can use XCodeBuild to run unit tests from command line
  • use GHUnit instead of built-in OCUnit to output JUnit XML reports
  • iOS Enterprise Development — O’Reilly book by James Turner
    • includes lots of useful
  • squish automated GUI testing?
  • test code linking…
    • app should be plugin host, providing linked libraries
    • but it doesn’t work — have to link yourself from test code

iOSDev UK: Building Custom Controls with UIView

Rory Prior, ThinkMac Software, @roryprior

  • generally subclass UIView directly
    • can subclass other controls, but things might not happen how you expect since lots of things happen in the background
    • and you may need to use private APIs…
  • override methods:
    • initWithFrame for programmatic creation
    • initWithCoder for IB-created views
    • drawRect for actual drawing
  • UIKit uses top left as origin
    • but CoreGraphics uses bottom left…
  • adding UIImageView is easy
    • but quite heavyweight
    • instead can draw a UIImage directly
  • similarly, can use UILabel or draw string directly
    • NSString drawAtPoint:withFont:
    • NSString drawInRect:withFont:
    • NSString sizeWithFont:
  • drawing shapes:
    • CoreGraphics (nasty low-level C stuff :-) )
    • UIBezierPath (introduced in iOS 3.2)
  • complicated graphics often still done better by using bitmaps — UIBezierPath can be processor-intensive for lots of lines
  • UIColor can fill in patterns as well as flat colour

user interaction

  • override UIResponder methods to detect touches
  • you’ll need UIGestureRecognizers to detect swipes, pinches, etc
  • but use sub-views of UIButton etc to make thins much easier
  • see slides for nice example of adding UIResponder and UIGestureRecognizer
  • use the delegate pattern to send feedback from your view to the rest of your app

iOSDev UK: Beyond NSLog

Tim Isted, @timisted

NSLog, XCode and gdb

  • useful macros for logging:
    • __FILE__ (full path)
    • __LINE__
    • __FUNCTION__ (and __PRETTY_FUNCTION__)
  • NSStringFromSelector(_cmd) gives you current message
    • Lots of these useful NSString functions, e.g. NSStringFromCGRect
  • use macros in log define
    • non-debug version should be something like: TILog(...) do {} while (0)
  • XCode preferences > Behaviours
    • Run starts — can choose what displays
  • XCode also has a variables view, hidden in the next pane of the debugger
  • add breakpoints for exceptions or non-source code by using little plus button at bottom of breakpoints pane
  • breakpoints have really useful options
    • log to console on hit (with auto hit count)
    • continue automatically
    • only do stuff on conditions
  • gdb commands:
    • s = step = Step In
    • m = Step Over
    • c = Continue
    • p = Print
    • po = Print Object
  • debugging Core Data: use [self valueForKey:@"propertyName"]
  • can use addresses instead of variable names in po
  • can make breakpoints user-specific instead of project-specific

Instruments

  • Time Profiler — great for catching infinite loops!
    • shows you time spent at certain places in call stack
    • tick the “Show Obj-C Only” checkbox
    • look for purple user symbols!
  • Heap Shot tool find leaks
  • quite a few WWDC videos on Instruments

iOSDev UK: Programming iOS Sensors

Alasdair Allan, Babilim Light Industries

http://programmingiphonesensors.com/

Magnetometer (it’s not a digital compass!)

  • 4th gen iPod Touch doesn’t have magnetometer
    • so no outside AR apps without markers
  • UIAccelerometer API newly deprecated for CoreMotion in iOS5
  • if you want compass heading but not location, then just start up [locationManager startUpdatingHeading]
    • you won’t get location updates warning
  • however, magnetic north varies across the world
    • there’s a big lookup table in the iPhone that can translate the magnetic heading into true north
    • so you need actual location to work this out
  • watch out for device orientation: magnetometer always reports heading pointing out of top of device
    • need to rotate according to device orientation…
  • local magnetic anomalies cause a fluctuating magnetic field — which is when it tells you to wave your device around
  • Earth’s magnetic pole is a quadrapole, not a bipole — it swaps over every now and then and the north pole goes south

Gyroscope & Accelerometer (CoreMotion)

  • iPhone 4 has more bits in its accelerometer sampler
  • combining gyroscope and accelerometer provides very accurate device attitude
  • if there’s no natural timer in your app, then you may have to use the push API
    • otherwise much easier to use pull API
  • CMMotionManager should be treated as a singleton (but API allows you to create multiples…)
  • monitoring does take a lot of CPU, so remember to stop it when you’re finished
    • device motion at 100 samples/sec uses 65% of iPhone 4 CPU
    • see “Pushing Device Motion” slide
  • you can fetch a frame of reference and then work out attitude relative to that

AR Toolkits

External accessories