Tag: iosdevuk

  • #iOSDevUK: Natasha Murashev – The Swift Architect

    #iOSDevUK: Natasha Murashev – The Swift Architect

    My notes from @NatashaTheRobot‘s talk at iOSDevUK.

    drawing
    Credit: PixaBay / stux

    2014 – when swift came out. Everyone was like what’s going on? People clapped but hesitant. Some people were unhappy. Especially people who had just learned Objective-C. Scary time. Everything I know has changed. Genius with swift is it looks very familiar. If you have worked with any other language. Obj-C was pretty alien.

    Immediate – genius of swift. Whole new language, but you kinda know it.

    Flappy bird – the hello world program of 2014. Felt behind right away. After WWDC everyone went back to their job, app was in Obj-C. Kinda died down. Was weird, this is not Obj-C anymore. Functional programming in Swift book. Until then just using very basic swift. Doing what always knew, just doing it in Swift. Only understood like 10%. Was like – wow Swift is not this easy fun language, it can get pretty complicated, I have a lot to learn.

    When you’re learning Swift, see a lot of Obj-C devs, start writing in Obj-C but in Swift. You can do that, and Swift is made to do that, easy to fall into that habit. But be a swift architect, use the power of the language to make your code better.

    Start with a blank slate. Have to question all your assumptions. Have all these schemas in your brain. It’s quick. Learning something new is painful. Have to relearn your habits, learn to think in a new way.

    Different learning strategies. Become an active learner of the language. Work with others. Learning and the social context is one of the best ways to learn.

    Working with senior devs, pairing a lot. Learned get the answer, see if there’s a better answer, then a better one.

    Teaching. Does a lot of speaking and blogging because forces her to learn. One level of learning you might skim it. But when you’re teaching it you have to really know your stuff.

    Put yourself out there. People get hesitant, because it’s not perfect, what if other people critique it? Always learning, Just like this is me at the time. Putting it out there, get a lot of comments. Internet is filled with really smart people. Write a blog post, get suggestions. Obviously sometimes you get the bad comments. We want to be at the place where everyone can feel comfortable putting something out there. When someone does make the effort, be on the nice side.

    Expose yourself to advanced topics. Learning is a wonderful experience because you have to admit that you don’t know something. You have to fall and learn multiple times. Community has an “I know everything” attitude. Need to be OK with something being hard and take a while to learn it.

    Celebrate breakthroughs. Have a moment of happiness whenever learn something, even if think it’s a really simple thing that everyone else knows.

    “Never put yourself in a position where you’ll be treated as foolish for learning” – @ashsmash – if people aren’t open to you learning either change that culture or put yourself in a better place where people are open to you learning.

    Three things That Stood Out

    • Value Types
    • Optionals
    • Testing

    Value Types

    Obj-C operates all in reference types. Pass the location of the object, and then modify the same one object. In Swift, value type heavy. Structs. Emums. Tuples. Pass a copy of that value, not a reference. The original thing has not changed.

    When switched to swift, made everything a class. Watching talks understood making things a structs or a value type.

    What about subclassing? For structs and value types, have to get rid of subclassing. For your own stuff, use value types. Use protocol orientated programming instead. Protocol extensions are magical. Classes are the exception rather than the rule.

    Swift standard library – 87 structs, only 4 classes.

    Optionals

    Can’t talk about swift without talking about optional. Started using options, fell in love with them. Like bumpers at the bowling alley. Kinda nice and fun and you always win.

    A lot of Obj-C devs come to swift, get frustrated, force-unwrap all optionals. Get rid of the bumpers – don’t do that.

    Sunset Lake did an audit of all their bugs. Found 40% would have been prevented by swift. Obj-C nil messaging was one of the biggest categories.

    Testing

    Swift makes it easier to test code. Culture in iOS of not testing. Apple has doubled down on testing. Adding a bunch of stuff in 2014 and 2015. Reason was because people were just making tiny fun apps, hacking culture, release your app and it’s fun. Now we’re at the point where mobile is first, flagship product for your company. No longer a little fun app, an actual product, have to think long term. You have apps that you’re starting, you don’t test, you get them out the door. Eventually it’s so hard, you rebuild the app from scratch.

    Swift is an opportunity to rewrite your app from scratch, time to write tests. Do you want something that you want to throw out in 2 years? Or something that people will still be happy to work on when you’re gone.

    Now there’s a testable framework, can test internal things, not private, just internal.

    Quick. BDD style framework. XCTest is not as fun with swift, it’s not made for value types and optionals. Sometimes just use nimble.

    Another thing testing does for swift, makes you write more functional. Remove side effects.

    Lots of excuses for why people don’t test. When want to move fast, do I test? How long do you move fast for? [tweet]

    Take cue from Apple. Going to build things that are here for the long term.

    “Live as if you were to die tomorrow. Learn as if you were to live forever.”

  • #iOSDevUK: Maxim Cramer – Users Don’t Bite

    #iOSDevUK: Maxim Cramer – Users Don’t Bite

    Credit: Wikipedia
    Credit: Wikipedia

    First thing learned when starting to make apps. Was making an app about beauty products. Went looking for people who would purchase beauty products (Oxford Street!) started in Starbucks.

    Asked for 5 minutes.

    People were really nice, if it wasn’t for them wouldn’t have discovered how hard it was for people to get to the product page.

    People daunted, confused, takes a lot of time.

    If release it like that you’ll get app store reviews of 1* “your app is shit”, this doesn’t help you figure out what is wrong.

    If you take the time to sit down can uncover issues and learn a lot in the process. Doesn’t have to have a 2-way mirror, can just sit down and learn the application and see what they do.

    Analytics will tell you what, but not why. We want apps to be intuitive. How? Listen to the people who use your apps every day.

    Why don’t we test?

    • We forget.
    • We don’t always know how.
    • We don’t see the benefit.
    • We’re scared.

    Getting involved makes you a better developer.

    Running automated tests isn’t enough, need to get your hands dirty.

    WHY do it?

    1. Save dev time, throw away less code.

    Money transfer site.

    • 9 months dev
    • Tested day before launch.
    • Ranked lowest in comparison to competitors.
    • CEO pulled the plug. Not launching tomorrow.
    • If people couldn’t use it, would just get a bad rep.

    Build a better product from day 1.

    More code you write the better you are at it. Same for this. Devs get better at tackling problems, the more you watch users struggle.

    • We can help. We know what’s possible.
    • Can see what people are trying to do, build it, make it easier for them.
    • Data driven decision in your team.
    • Know how it works, but can be surprised when put it into someones hands.
    • Tap and hold (iOS), suggested for edit a note. People disagreed, but thought it would work. Put it into user testing and everyone managed just fine. People knew, because it’s how you delete apps. Could have turned out the other way, but at least now it was based on some kind of data.
    • No-one starts out with all the answers.

    SwiftKey been doing this for the past few months. Had no time to lose, tested every single week.

    • Helps you understand changes.

    Spent ages working on something, want to know why. If you see someone struggle, makes a lot more sense.

    • Helps connect to the people you build for.

    When stuck behind your laptop don’t see scared face. Someone who doesn’t get what they should do.

    E.g. “the case of the missing text” – can’t let it go when seen someone experience that. Can’t ship with a bug like that. Fix it.

    How Does This Fit In?

    • Do I have time for that?
    • Depends on how you work. UX team.
    • Watch one session a week (if do weekly testing).
    • Brings people and experiences into discussions.
    • Put it into people’s hands.

    DIY

    Need people.

    • Target audience.
    • 5 people.
    • 80% usability issues.
    • Aim for 6-8.

    Content

    • Tasks
    • Prep
    • Observations
    • Prompts
    • e.g. Could you delete a notebook?
    • Have to have the right content
    • Follow up from previous tasks.

    Pointers

    • Do they ever swipe?
    • Can they press buttons easily
    • How do they respond to a prompt?

    Promtps

    • How would you think you could do that?
    • How do you do this normally/elsewher?

    Ask:

    • What do you think happened to the content?
    • Did you feel you could do this by accident?
    • Why did you do what you just did?
    • What did the action remind you of?

    Measure

    • How easy was that?
    • What did you like?
    • How could it be better?

    Preparation.

    • Welcome them
    • “We’re testing the product, not you”
    • “Please, talk out loud”
    • “Nothing will offend us”

    Interaction During the Session

    • Don’t help
    • Don’t encourage
    • Use your prompts
    • Keep the conversation going.

    People say devs shouldn’t do user testing. Because we made it, so much easier for someone independent rather than involved. Subconsciously will smile when they get it right, be annoyed when they get it wrong. Users want you to be happy, will try and please you.

    (Solves this by being enthusiastic all the time)

    Closing Qs

    • Repetition of good and bad
    • “how much would you pay?”
    • likelihood of recommendation (1-10) (NPS)
    • “What would we need to get to that 10?”

    Tips

    • Focus on observation
    • Be positive
    • Be conversational

    Outcomes

    What do do with results? Fix them. Any major issues will surface

    There’s nothing like watching someone in love with what you made.

  • #iOSDevUK: Tehila Sabag: Mobile Monetization – Navigating in a Free Eco-System

    #iOSDevUK: Tehila Sabag: Mobile Monetization – Navigating in a Free Eco-System

    My notes from Tehila’s talk at iOSDevUK.

    no ads
    Credit: Wikimedia

    StartApp – mobile monetisation platform. Brains and beauty of the mobile industry. Right ad, right time, right user. Using BA tools and data. Beauty side – most engaging and appealing ads.

    How do you make your app stand out in a crowd?

    How do I retain the user?

    How do I monetise the user?

    3 Application types:

    Flash light click

    • Can generate a lot of downloads
    • Many free alternatives
    • Minimal usage time
    • Similar apps – wallpapers. widgets calendar.

    Action game

    • Super popular
    • Addictive
    • Similar apps – strategy games, puzzles, gambling.

    Music player

    • loyal users
    • long sessions
    • many features
    • similar apps – social apps.

    Paid app

    • Don’t go there.
    • 90% of apps on iTunes are free.
    • 95% of downloads are for free apps.
    • 90% of paid apps being downloaded less than 500 times per day.
    • Top growing apps on iTunes. Only paid app is Minecraft.
    • Not a recommended business model, but you can try.

    Banner adds

    • Most popular.
    • Bring traffic, network places adds.
    • Over 400 networks (admob in 40% of free apps)
      • Acceptance from users
    • ECPM is your BFF.

    Do this:

    • Plan and integrate ahead.
    • Engage at the right time (exit point).
    • Use – fill page, app walls, video. Full page interstitials have best ECPM.
    • Test, test and test some more.

    Avoid:

    • Use only classic adds.
    • Misplace adds – disrupt UI/gameplay.
    • Don’t be ad-blitzing.
    • Settling for the first network you try.

    Clock widget:

    • No space for ads.

    Action game:

    • Suited for interstitials.

    Music player.

    • Relevant adds.
    • An attention catcher.

    Summary:

    • Use a variety of ad units.
    • Strategically place banners.
    • Analyse performance (need to learn and know the users behaviour, change according to what you see).
    • Take advantage of tracking tools.
    • To make this work, need a LOT of traffic (need a lot of daily actives).

    eCPM

    • eCPM = CR * CTR * layout * 1000
    • CTR
    • CR
    • Factors that impact both CTR and CR (engagement of users with the ads).
    • Payout.

    More users click on full screen ads rather than small ads. Need to take that into account.

    Freemium.

    • Application is for free.
    • Inside a variety of options for purchases.
    • Dominated by games.
    • Numbers are mind-blowing (e.g. Candy Crush).
    • Don’t go into making a game expecting these numbers, but huge potential.

    How to make it work:

    • Plan from day 1
    • Make it highly addictive.
    • Offer purchase at the right time.
    • Create a currency. Even two.

    Issues:

    • Successful app – no child’s play!
    • Not a game? A lot tougher.
    • Need to “hook” the user.
    • Usually works for very high end games.

    Flashlight / clock:

    • Not an easy one.
    • You can try this.

    Action games:

    • Addicting.
    • Add a social layer.
    • Need to know when each user might agree to purchase.
    • Can be a great fit.

    Music player:

    • Pack it with features.
    • Offer a trial.
    • Can be good.

    Summary:

    • Great money making opportunity.
    • Plan ahead.
    • Best suited for games..

    Need to find a balance between UX and revenue.

    Summary:

    • Lots of opportunities.
    • Start with making a great app.
    • Don’t settle – test, explore, optimize, analyse.
    • Reach out to the other side – users and ad networks
    • You can turn this into a business.
  • #iOSDevUK – Luke Rogers: The Logic of App Design

    #iOSDevUK – Luke Rogers: The Logic of App Design

    converse bag-clothing design by michexist
    Credit: DeviantArt / michexist

    Design is a skill you can learn, the same way development is a skill you can learn.

    Design is not about making it look pretty, small percentage of it. About working out hierarchy, working out what is important.

    Brainstorm what the user should be able to do.

    • Not “have analytics”
    • Instead “watch a video”

    Order it, figure out what is most important. Useful later on in forming the importance in the UI.

    Cut out features that you can leave out of v1 at least.

    Study other apps. “Good artists copy and great artists steal”, “everything ia a remix” – Kirby Ferguson.

    Idea that being creative means having original thoughts. We all sample consciously and unconsciously all the time.

    Broaden the way you think about the problem. Most apps are just organising information in a structured way. Can pull from a wide range of apps.

    iOS look almost exclusively designed by Apple. Android, almost exclusively apps designed by google. They know the platform best and have thought about it a lot.

    Search is an interesting thing to study on iOS. Messages app has hidden search bar, have to scroll. Similar location in email but initially visible. App store and podcasts put search in the tab. Seems inconsistent, but with good reason. Depends on how central use case it is. Main task in app store, less common task in messages.

    Reuse is good “things that look similar are similar and should behave in a similar way”.

    One have a wireframe, can move to the computer. Like Sketch, more for app design. 35GBP one off purchase.

    Not all of your design needs to be exciting. Some things should be functional above everything else.

    Nothing is set in stone, everything is iterating the whole time.

    Familiar button, because traced over a similar one. Means user are going to understand.

    Prototype in keynote. has some great features, helping mock up transitions. Can export a mob, make the size the same as an iPhone screen, make a clickable PDF with clickable buttons. You can run it on your iPhone or iPad.

    Keynote iOS is landscape only, need to do everything at 90 degrees. But worth it to get something you can give to people to play with.

    Also, XCode. Exported central image and made it scrollable. Can look and see how it would behave.

    Consider empty states. What happens when things (e.g. location) are turned off. For error states, look at what other people do. Important when things are going on that users don’t feel frustrated or lost.

    Important to get feedback throughout the whole process. Beta testing. Not just about ironing out bugs, also about taking on user feedback, finding out what is confusing them, and being prepared to change stuff.

    Valuable time to sort things out before launch. After launch, make sure you have a way for the user to send you feedback. Users invest in the product, make it easy for them to send you feedback. Inform what is important in the next phase of the app.

    Process:

    • Brainstorm
    • Study and remix
    • Rough sketch
    • Mockups
    • Prototype

    ITERATE

    Principles:

    • Focus on structure
    • Sample and remix
    • Don’t be arrogant – don’t think you know better, listen to feedback. don’t have to implement everything but take it onboard and consider it.
  • #iOSDevUK: Hamish Allan – The Pareto Principle

    #iOSDevUK: Hamish Allan – The Pareto Principle

    80/20 modular framing
    Credit: Flickr / Alexander Pfeiffenberger

    App store offered a way for people who were interested in writing software to make money from writing software.

    Have recently found need to do more advertising. Even more recently, take on more and more contract work.

    Identify as devs, but need to learn more sides of running a business. Pareto principle is thing that can help here.

    What is it?

    • 80:20 rule of thumb.
    • Doesn’t have to be 80 and 20.
    • Doesn’t even have to add up to 100.
    • 80% of effects come from 20% of causes.
    • Cause and effect are not necessarily linearly related

    Vilfredo Pareto

    • 80% of the land is owned by 20% of the people.
    • Economics based on observation, transformed into scientific discipline.
    • Adam Smith was more of a philosopher.
    • 80% of peas come from 20% of pods.
    • In 1980 countries with richest 20% of world population had 82.7% of GDP.
    • Up from 70.2% in 1960.

    If you have an 80:20 rule, alpha param has a value of about 1.16.

    Project Management

    • 80% of value is achieved with the first 20% of effort.
    • The last 20% of an app takes 80% of the time to write.
      • If writing a mail app, got table view done, might think 40% done, but only 1/600 of the way there.

    Your own apps

    • Five 80% coplete apps versus one 100% complete.
    • Ask, should I be writing more apps?
      • Do you write one app and make it the best you can, or diversify.

    Contract Work

    • If possible, avoid estimating for completed projects.
    • Easier to estimate 80% of what they want.
    • Bid for a phase 1. 80% of what they want, in 20% of time.

    In Engineering

    • 80% of bugs in 20% of code.
    • A large number of bugs come from a small number of classes of bugs.
      • E.g. memory management. Arc destroyed a large class of bugs that took up so much time.
      • Multithreaded programming. Dispatch queues address this.
      • Asynchronous programming.
      • Type safety (swift).
    • 80% of processing time is spent in 20% of code.

    Design

    • 80% of your app’s usage is 20% of it’s features.
    • Optimize for the common case.
    • Especially at resume time.
    • Be opinionated
    • Especially if you change rather than just adding.
    • They will ask you to add a switch in settings. Try not to do that.
    • Paradox of choice – if you present a lot of choices, it stresses them. Makes the app less usable for them.
      • Developers might be OK with it but a lot of people find it stressful to be presented with so many choices.

    Support

    • 80% of your support is for 20% of your customers.
    • Check if they haven’t paid and ask for support.
    • Like getting blood from a stone. Try and engage in a conversation just don’t.
    • Answer terse emails briefly.

    Sales

    • Not quite as applicable on the app store because leads don’t work the same way.
      • 80% of sales come from 20% of your products.
    • 80% of your clients come from 20% of your leads.
    • Don’t do too much work for free.

    Productivity

    • 80% of work is copleted by 20% of individuals.
    • 80% of work is completed in 20% of an individual’s work hours.
      • Hard to optimise for that, downtime is important for perspective.
    • Best teams have people who can code quickly, and people who are always trying to put the breaks on and take a wider perspective.
      • Need both of those types of people and everyone else in between. Or individuals taking both of those approaches.

    Bunch of places where you can apply. Helpful for people who want to make a business coding.

    You must measure. It’s a discipline. You can make assumptions about where the low hanging fruit are, but until you measure you don’t know.

  • iOSDevUK: Kenton Price: Teaching Your Client Android Design or Don’t be an iPhoney

    iOSDevUK: Kenton Price: Teaching Your Client Android Design or Don’t be an iPhoney

    android fragmentation 2014
    Android Fragmentation 2014 / OpenShift

    The problem: Android devs generally given designs for iPhone. “But that’s just like Android, right?”

    Rid the world of these iPhoney apps now.

    Used to be like windows apps on Apple. People still do iOS first, Android is an afterthought.

    Android users want Android apps.

    Android users can tell when it’s an iPhone port.

    Android users will slate you if you’re a lazy sod. Poor engagement. App won’t be a success.

    The problem with graphic designers: Designers design to the pixel in photoshop. Pixel perfect designs for two sizes.

    You can do it for iPhone (3, 2 duplicates), but not for Android. Popular app, had 428 different screen resolutions one month after going live.

    Pixel perfect for Android is impossible:

    • Use principles of responsive design.
    • Define stretch areas, horizontally and vertically.
    • Use spacers.
    • Define boundary points (doesn’t work for Gingerbread and earlier)

    Problem with designers:

    • Talk in pixels, not in DIPs (density-independent pixels) or SPs (scalable pixels).
      • Everything in Android should only be designed in DIPs, test in SPs.
    • They measure to font baseline, not font padding.
      • Helvetica and Roboto look similar, but have very different padding.

    Designers need to learn Android:

    • Teach them DIPs and then SPs.
    • Try “DIPs are like pre-Retina pixels”.
    • Teach them responsive app design.
    • Teach them Android Design Guidelines.
    • Landscape mode is a first-class citizen.
    • Have an intervention – confiscate their iPhones.

    Big no-no’s:

    • iPhoney icons.
    • Back button of doom (don’t have it, use the physical one).
    • Carets of contention (don’t put carets at the end of list view lines).
    • Big up, big downer.

    Navigation is owned by the platform:

    • Use Android navigation patterns on Android.
    • Action, navigation bar, view pages.
    • Keep is 100% Android above the line (navigation bar, draw).
    • Use action bar action mode.

    Get the action bar absolutely right:

    • Ensure up button works everywhere.
    • Use 70/30 rule for action buttons.
      • If needed 70% of the time, bar, else in menu.
    • Use official Android navigation drawer.

    Avoid developer art: nail your specs.

    Need to work with designer to get the specs absolutely right.

    Material Design:

    • Announced at I/O in June.
    • Material is the metaphor.
    • One adaptive design.
    • Unified experience across multiple devices.
    • Consistent look and feel.

    Case study: The Sun Mobile

    The Sun saw an earlier version of this talk at Droidcon last year.

    • Same as iOS with Android navigation.
    • Responsive design.
    • Add Android extras: here, a daydream (whilst your phone is charging).

    Reactions:

    • Feedback creeping up, was 2.9 now 3.4.
    • Customer is delighted, particularly with the on boarding.
    • Has commissioned lots of follow-up work.

    Case study: BBC Weather

    • Enormous brand, Unbelievable market share.
    • BBC identified need for a weather app.
    • Unsure whether to go native or responsive.

    Designs were iOS designs.

    Professional designers say “this should be android”, get this as an Android dev all the time.

    Add fun Android stuff:

    • NFC support
      • So many reviews picked up on this.
    • New android features:
      • Lock screen widgets
      • Daydream mode
      • Dashclock
    • No need to shout about it, early adopters will do it for you.
    • Ratio of 5* to 1* reviews was 100:1
    • Featured in play store.
    • Client really happy.
    • #1 free app for a while.

    Summary:

    • Get product manager onside with Android.
    • Get graphic designers on board with Android. They need to understand what you are doing.
    • Suggest where Android can improve the product.
    • Compare to best-of-breed to argue.
    • Get Action bar absolutely right.
    • Add Android-related flourishes and fun stuff.
  • #iOSDevUK – Sally Shepard: Beyond VoiceOver

    #iOSDevUK – Sally Shepard: Beyond VoiceOver

    Surprise Attack
    Credit: DeviantArt / SkylerTrinityRapture

    My notes from Sally Shepard‘s talk on Accessibility at iOSDevUK. It was really good, I thought I knew quite a bit about a11y but actually only VoiceOver really, so I learned a lot. Her slides are here.

    Passionate about accessibility, accessibility issues in family.

    Myths:

    • Not that many people.
    • Time consuming.
    • Too complicated.
    • Don’t know how to test it.

    1 in 7 people have some form of disability. It’s a growing population. This doesn’t include temporary impairments (break an arm, finger). Disabilities can make life extremely difficult. Can use technology to overcome these challenges.

    Vision:

    • Complete blindness.
    • Degeneration.
    • Diabetes.
    • Impairments.

    Wide range. how do these people use iOS?

    VoiceOver

    • Replicates the UI for users who can’t see it.
    • 36 languages.
    • On iOS and OS X, iPod shuffle.
    • Can also extend using braille.
      • Brail displays.
      • Brail keyboards.
    • Makes a device that is completely usable for wide range of people that wouldn’t be able to otherwise.
    • Single tap to hear. Double tap to open.
    • Camera app. Demo – finally understand face detection.
      • Wouldn’t have thought camera could be accessible.
    • Demo Text edit.
    • Demo Flappy bird. Voice over doesn’t see anything on the screen.
      • If an app isn’t accessible, it’s just like a blank screen.

    Make Views accessible using isAccessibilityElement. Can also set accessibilityLabel. UIKit uses the title. Image based controls need to specify this! Don’t include the control type.

    accessibilityTraits: Combination of traits that best characterise the accessibility element.

    accessibilityValue: Used when element has a dynamic value. Like a slider.

    AccessibilityHint: Describes outcome of performing an action.

    Adding support to xib or storyboard:

    • Enable a11y.
    • Fill out label.
    • Add hint traits.

    Adding support programmatically:

    • Set label.
    • Set hint.
    • Set value.
    • Set traits.

    Most apps have moved beyond basics. gestures, games. Handle this by finding out if user has voice over on, and if so, present something different.

    UIAccessibilityCustomAction: Can add multiple actions to an element. e.g. array of actions on a table cell. In apple’s own apps since iOS 7, now in the API for iOS 8.

    UIAccessibilityContainer: Specify the order voiceover should go through the elements.

    accessibilityActivate added in iOS7. Gets called when user double taps. Good when gesture is normally used to activate.

    DirectInteraction. Have to be careful about how you use it.

    A11y notifications. Know if VO is speaking, when it has finished speaking. Can tell it to read things out at specific times.

    Two finger double tap. e.g. in camera, will take a picture.

    What if not using UIKit? Implement UIAccessibilityContainer protocol. VoiceOver just needs to know the frame of the contents and where they are on screen. Good sample code from WWDC.

    Testing VO:

    • Test plans
    • User stories
    • Use cases
    • Do all of these with VO.
    • Simulator good for debugging. Use accessibility inspector.
    • A11y shortcut – triple tap home button. Or tell Siri!
    • Screen curtain. Three finger triple tap on the screen. good way to conserve battery! Makes sure you are not cheating.

    User testing:

    • @applevis
    • WWDC labs
    • Charities and local councils
    • Support groups

    Motor skills: Maybe can’t perform gestures, or press buttons, or hold a phone. In that case, device is blank screen. Can’t do anything with it.

    Assistive touch: Can access things like more fingers, gestures, shaking.

    Switch control: In iOS 7. Allows people to use device by using a series of switches. Can be used by hands, feet, head, anything. One switch or multiple switches depending on abilities.

    • Camera with switch control, take a picture.
    • Flappy birds with switch control. not very successful!

    Amazing feature, v necessary, glad they added it.

    Adding support for switch control:

    • Find elements that have actionable behaviour
    • If you’ve gone through a11y APIs for voiceover, should work.
    • Could make it better, if you did the a11y container protocol, specify a better order.

    Have to test on a device. Simulator only gives you inspector.

    Go though, same thing, make sure you can do the things you app does.

    Contact apple, super happy to help with things like that. Talk to local charities or user groups.

    Learning Difficulties

    Autism, or cognitive disabilities. iOS can be distracting, because it’s quite an engaging experience. How does someone use it?

    Guided accesses. Helps them focus. Parent or care giver can specify what actions shouldn’t be allowed.

    UIAccessibilityIsGuidedAccess, new in iOS8

    Visual accommodations:

    • Is bold text enabled
    • Reduce transparency
    • Darker system colors
    • Reduce motion

    Why add a11y?

    Things to do:

    • Push to OSS projects you use
    • Talk about it more – blog about it
    • Get involved
    • Still a LOT to do
    • Even if it seems like only a few people you can make a big diff

    Try:

    • Spend a whole day with voice over on (very few support it)
    • Take one weekend to do something with a11y.
    • Work with charity to run a hackathon or hack day
    • As a dev it’s up to you to make your app a11y

    Facts:

    • Is a lot of people, 1 in 7
    • Very simple to add
    • No app is too complicated to be a11y
    • Testing is straightforward
  • #iOSDevUK: Jon Reid – Controlling Dependencies to Enable TDD

    #iOSDevUK: Jon Reid – Controlling Dependencies to Enable TDD

    My notes from John Reid‘s talk at iOSDevUK.

    digital wires
    Credit: DeviantArt / LoneWolfAssassin

    Barriers to TDD. Two primary:

    • Not knowing what it is. Rejecting it as silly without giving it a try. A good try, as there is a learning curve. It will slow you down at first. If you give up before the payoff then you will say “oh that was stupid”.
    • UI and Networking. On iOS most of what we do is UI and networking, rules out 90% of app, so not really useful.

    EBay Fashion app. All test driven.

    3 Types of Unit test:

    • Return value test
    • State test
    • Interaction test

    Patterns of testing. The Design Patterns book, the Gang of Four never intended it to be the beginning and end of design patterns.

    Not going to be rocket since. About getting through the barrier. Writing unit tests after if necessary, but ideally before.

    Return Value Test:

    • Arrange: set up object.
    • Act: Call method that returns a value.
    • Assert: Compare against expected value.

    With this alone, you should be able to get a very far distance. Onboarding engineers at Facebook, teach them not to be shy about extracting stand alone functions. Helps overcome that barrier.

    State test:

    • Arrange: Set up object.
    • Act: Call method.
    • Assert: Compare against expected value.

    Since interested in a side effect, just need an additional call to verify state. Should be able to write quite a few tests with these two techniques.

    Interaction Test:

    Don’t need to be isolated units. They can be connected, as long as they are fast. Check that the system under test (SUT) is communicating correctly to something else.

    Don’t want to talk to the real thing:

    • Takes too long.
    • Might not be there.
    • May not have everything (don’t want to use things up).
    • Might want to test the failure (normal end to end tests).

    Want a fake thing that the test can control. Need dependency injection, if the middle thing is creating the end thing, it’s hard to test.

    Dependency Injection:

    • Extract and Override.
    • Method injection.
    • Property injection.
    • Constructor injection.

    Difference between having a singleton, and a single way to access a singleton. E.g. NSUserDefaults. Don’t want to access it in this way.

    Extract and Override: read “Working Effectively with Legacy Code” (Amazon).

    TDD was working for me in a greenfield project, but how many of us get to stay in such a place?

    Seams

    Make a cut – subclass, override “userDefaults”, do what you want. Very powerful. Very effective with legacy code. Very dangerous. Like a drug. But will end up with the bane of testing code, fragile tests, because tests are coupled to implementation.

    For getting started, especially with legacy code – good technique.

    Method Injection

    Better for other things, like calling “[NSDate date]” – will cause havoc with tests. Can swizzle, or just pass in what time you want. Now you will have a method that does more, now it’s tied to any time, not the current time. Helpful as context for injected object is very small. When spans across method, probably want to hang on to it as a property.

    Test can inject the fake thing. But what about production code? Can end up with nil. Objective C will be like “whatever”.

    Create custom getter with lazy eval. If no value, get the default value.

    Inject in constructor – workhorse of dependency injection. Biggest benefit, makes everything explicit.

    Can be annoying to have everything explicit. Long chain of dependencies is a code smell – you have too many dependencies.

    Even then, you can simplify that, by using a Builder. Builder pattern creates the object you want according to however it is set. Set in any order, or not set and have it have defaults.

    Constructor injection is the main one.

    Ambient Context. Change something globally. Swizzling is an example of this. You can, sometimes helpful. But dangerous. Have to have your test restore the pre-test condition.

    Let’s learn some good things from other people in other disciplines. There are plenty of smart people who are not using Obj-C

    Interaction Test

    Types of Fakes: The Art of Unit Testing

    • Stub: Fake that provides a pre-canned answer.
    • Mock: Recording how it is called by the SUT, so that it can assert.
    • Difference is which way the test is pointing to make it’s assertion.

    Don’t need a DI framework in order to do DI as a concept.

    Mocking, if never mocked before don’t use OCMock or OCMockito at first. Use them eventually. Meanwhile, you can make your own fake. Subclass and override all methods. Test Driven iOS development, means don’t have to do that in Obj-C. Dynamic language, supports DuckTyping.

    Subclass NSObject. Put the method in. Use a simple property to record the number of calls. Have a fake return value (if unspecified is nil). Capture arguments.

    Interesting thing about doing by hand, answers question of “what do we do in swift”. No introspection available to us. Do it by hand, laborious, might cry a little bit, but nothing stopping us.

    Now we have a mock, use it. Start writing some tests.

  • #iOSDevUK – Martin Pilkington: Thinking in NSLayoutContraints

    #iOSDevUK – Martin Pilkington: Thinking in NSLayoutContraints

    My notes from Pilky’s iOSDevUK talk. It was so good that after watching it I actually thought I understood AutoLayout (I later discovered I was wrong). His slides (and notes) are here.

    cat in a box
    Credit: Wikimedia

    What is AutoLayout?

    • Constraint based layout system.
    • Define relationships between views.
    • Into in Max OS X 1.07, iOS 6.
    • Makes previously complex layout problems simple (i18n much easier).
    • Requires a different way of thinking about layout.
    • Fits more closely to your natural mental model – bit like a compiler. You don’t write everything in assembly. You write in a programming language, compiler translates.

    Constraints: How do they work?

    • Represented by NSLayoutConstraint (only class added for AutoLayout).
    • Defines relationship between two attributes.
    • Attributes are effectively variables. Can’t access directly, treat them as constraints.
    • Treat a constraint as a small function modifying a variable.
    • y = mx + c
    • view1.attribute = multiplier * view2.attribute + constant

    Attributes

    Effectively variables, so what do we have:

    • width
    • height
    • centerX
    • centerY
    • baseline (for text)
    • Left leading. Right trailing, Top, Bottom.
    • Left and Right – left to right language, equivalent. In R to L language, left becomes trailing, right leading.
      • Want the entire information flow of your app to swap around.
      • Used to have to do this yourself, now get it for free.

    Relationships

    • Equal
    • Greater than or equal to
    • Less than or equal to
    • Becomes more important with different size devices. Want things to resize smartly.

    Multipler and Constant

    • Multiplier: ratio between two attributes.
    • Constant: difference between two attributes.

    Priority

    • How strongly should a constrained be satisfied.
    • Constraints required by default.
    • Constraints can be broken. Optional constraints.
    • Required constrains have priority of 1000.
    • Allows us to build a hierarchy of constraints.
    • If two conflict, lower one will be broken to satisfy higher one.

    YOUR NEW MENTAL MODEL

    How should you be thinking?

    Relative vs Absolute

    • Don’t think in frames, think in relationships.
    • Most constraints are relative to other attributes.
    • No need to do complex calculations based on other views.

    Thinking in Values

    • Can be hard to work out what attributes, constant etc. to use.
    • Don’t think of them as abstract values.
    • It’s an equation – substitute in numbers.

    Constraining a View

    • All views need at least 4 constraints.
    • Need to position and size in both horizontal and vertical axes.

    Intrinsic Content Size

    • Views know how to layout some content.
    • Therefore they know the smallest size to display that content.
    • Implicit constrains defining intrinsic width and height.
    • Stronger constrains is compression resistance (p. 750, prevents from clipping).
    • Helps a lot with localisation.
    • Never want to specify explicit height or width, especially one that is showing text.
    • Used to have to change things manually on i18n. Now with auto layout you don’t. Saves a lot of code.

    Calculating UITableViewCellHeights

    • Autolayout and UITableView.
    • Create table cells as any views, adding constraints to define height.
    • Use systemLayoutSizeFittingSize: to return height.
    • Get a cell from the table view:
      • Set a vertical constrain to have priority 999.
    • Or use template cell.
    • Set estimatedRowHeight to most common height.
    • Ensure rowHeight is UITableViewAutomaticDimension.
    • Set it to anything else, all the same problems as iOS6 and 7.

    Autoresizing UIImageVIew

    • Subclass UIImageView
    • Add following:
      • overrideIntrinsicContentSize:
      • overrideSetImage: (need to relayout).
    • If too big, will appear off the screen. Need to specify maximum size.
    • Cannot use external constraints, only those from the view hierarchy.
    • Reason for preferredMaxSize property.

    Switching Orientation

    • Turn constraints on and off (bit of a hack).
    • Make them optional. Set priority depending on orientation.
    • Set constrains priorities to 999 to enable.
    • Set to 1 to disable.
    • Many problems with this.
      • Theoretically, priority 1 constrains should never be satisfied.
      • But potentially it could be.
    • iOS8
      • New active property.
      • Set to yes, take into account.
      • Set to no, not taken into account.
      • activateConstraints: for bulk changes.
      • Use NIBs with size classes.

    Animation

    • Frame based animation.
    • AutoLayout based animation.
      • AutoLayout is simpler, if the views are already there.