or

How to make a basic interface perform really well.

Problem

From time to time as a developer working on an iOS project you might see a ticket of work like this:

I see this ticket in many iOS projects and the reason it ever exists in my opinion is that behaviour of interfaces is often not specified and therefore a developer can think that their job is done when it actually isn’t.

Here is a video of the problematic behaviour:

There is a repository for this post and here is a link here. If you select the branch ‘problem’ you can see the issue above.

Let’s fix that ticket!

Goals

1. Zero changes the layout (UI)
2. Keep any information on the view available to the user at any time.

We will do this by making the view scrollable so that as soon as the user taps on a UITextfield the view moves up above the keyboard and if the user wishes to scroll the view to see content that is now off screen they can do so.

Solution

Step 1: The storyboard doesn’t have a UIScrollview in it so the first thing we need to do is get the current content into a scrollview.

This is easiest achieved by first putting all the components of the view into a separate UIView which will become the content view of the scrollview.

The new view will be our content view so let’s call it that in the storyboard.

Notice that we have broken a ton of constraints and now Xcode is highlighting the broken and missing constraints in red. We will fix these issues shortly.

Step 2: Now embed our content view inside a scroll view. This time it’s fine to leave the naming to Xcode as it uses ‘Scroll View’ automatically.

Step 3: Fix those broken constraints.

First make sure that the components of the content view fit correctly as desired within the content view. Then:-

This is the important bit

The scroll view should be pinned to it’s superview which is pinned to the Safe Area.

The content view of the scroll view should also be pinned to the superview of the scroll view (in our project this is the main view).

Why are we doing this?

Let’s remind ourselves how a scroll view works. If the content of a scrollview is the same dimension (or less) than that of the scroll view itself then the scroll view does not scroll.

For the scroll view to scroll the content of the scroll view must be of a greater dimension that the scroll view itself. We will take advantage of this behaviour to achieve our desired behaviour by adjusting the position of the bottom of the scrollview when the keyboard is on screen. Doing so will make the content of the scroll view greater than the height of the scroll view and it will become scrollable.

One last adjustment before we recap the constraints. Reduce the priority of the content view height to 250. This will mean that the height constraint of the content will be lower than the constraint pinning the content to the bottom of the scroll view. This is essentially the magic.

Recap:

We can test that the magic will work. Temporarily change the background colour of the main view to a light grey and then adjust the constant of the constraint which pins the scroll view to main view. I changed it to 100 and this is what should happen in your storyboard.

Step 4: Now we need to stitch together our storyboard work with some code.

Instead of working in the ViewController class lets create a BaseViewController which can act as our super class for the ViewController and keep all of this code which once working we can then forget about and better still not have it cluttering up our ViewControllers which need to be concerned with other work.

Step 5: @IBOutlet

Lastly dont forget that there is now an @IBOutlet which needs to be linked up.

Recap:

The new super class BaseViewController adds behaviour in three ways.

1. Firstly it observes two cocoa touch events

UIResponder.keyboardWillShowNotification
UIResponder.keyboardWillHideNotification

When those events occur we know it’s time to adjust the constraint on the bottom of the scroll view.

2. Secondly it adds a tap gesture to the view so that the screen will be reset when after the user taps away from a text field.

3. When the ‘Return’ key on a UITextField is tapped the screen will be reset.

Results

Code

Finally here is the link to the solution code.

Thank you for reading to the end

or

Ticket discipline starts in elaboration.

When we work in an agile environment we can expect to be given work in ticket form. The ticket is one of the glues of the agile environment, so it follows that good tickets promote a good working environment and bad tickets …

don’t.

What happens when there is a bad ticket?

A ticket can be bad in many ways but when it is bad then it’s guaranteed that:

1. Developers wont know what needs to be developed.
2. Quality Assurance will find recognising quality especially difficult.
3. Managers wont know what’s being done and when.
4. Managers wont recognise when there are genuine blockers ahead.

In short: When there are bad tickets, bad things happen.

What makes a ticket bad?

🛑Size: If your team looks at a ticket and assigns it 13 points, or 8 points. Odds on, that ticket is simply too big to handle. Sure, some things in life are complicated and the complexity needs to be recognised however if we assert that a team member only has a fixed capacity of points each sprint it’s easy to see that large tickets will take up large amounts of that capacity. Having a team member spend half of a sprint on one ticket is too much; reason:

There will be dependencies on tickets and there will blockers on tickets, so to minimise the impact of dependencies and blockers we need to make tickets small.

Small tickets are maneagable tickets.

🛑Duplicates: This is obvious right? No-one would create a duplicate ticket deliberately, but, what if two tickets are ‘almost’ duplicates of one another? What if your team are creating a sprint board that resembles a Venn diagram of tickets? If you look at the sprint board and see five tickets that all overlap one another then you are in for a painful ride.

Tickets need to be visibly distinct from one another

If you find that that tickets are literally bouncing of people’s eyeballs without them noticing or understanding the contents of the ticket then it’s a certainty that your tickets are not distinct enough from one another.

Several bad things can happen at this point, not least that the wrong work gets done on a ticket but also that team members stop looking at tickets as single pieces of work.

Instead they pick up two or three tickets simultaneously and work on all the tickets at the same time:

You need to recognise that, when a team member picks up 26 points of work in one go, then it’s an immediate red flag!

If it’s more effort to pick tickets apart than it is to attempt all the tickets at once then you have created Venn Diagram tickets.

🛑Incomplete: You’re sat in the elaboration meeting and everything is crystal clear. Everyone present understands the task and everyone agrees that the text on the ticket acurately describes the task in hand.

Later, may be near the end of sprint the ticket is picked up. It’s at this point that it becomes apparent that not everything that was known at the time of elaboration, is explained on the ticket. Something, maybe several things have been omitted from the ticket and what once made sense, now makes no sense.

We all know about ‘ticket discipline’ which is, “When I pick up a ticket, what do I need to do?” but after reflecting on all of the above, to me it seems that:

Ticket discipline starts during elaboration.

&

Ticket discipline is a team discipline.

During elaboration, it’s the teams job to make good tickets.

Tickets need to be:

✅Small - so they are maneagable.

✅Distinct - so they cannot be confused with other tickets.

✅Complete - so everything you need to know is right there on the ticket.

Thanks for reading this far. Why not give me a clap and / or leave a comment.

The Springboard or app switcher is the UI/UX interface in iOS for switching between applications. It’s great but sometimes as developers of apps, we forget that the iOS is evolving with each release and some behavioural changes can trip us up.

Recently, a tester working on an app with me pointed out that it’s posible to see sensitive [payment] information on the app while it is in the springboard. This shouldn’t happen and the app had previously employed a [working] technique to obscure this information. Something had “broken”.

So, how often do you check that your security features are still working as expected?

Do you do it every time a new iOS is released?
Every time a new iOS minor release is available?
How about every time you release a version of your app?
Bro, do you even regression test?

What just happened?

The technique employed to mask sensitive application is a common one.

1. When the app is resigning active
2. Load an image
3. Display it over the window

I looked at the code in applicationWillResignActive

Pretty standard stuff; I checked and it was still getting called so what the … ?

Test, test a lot. No, more than that…

So, we tested a bunch more, we tested … a lot. It turned out that if we single pressed the home button the app would always behave and show the lock screen. But if we double pressed the home button (go straight to Springboard) the app pretty much always failed to show the lock screen. this kind of behaviour happened on all our test devices, iPad or iPhone which was a real big surprise.

Timing

Turns out that loading an image with UIImage.named takes time and it takes more time than modern iOS was willing to supply when resigning active and heading straight to the Springboard. This security feature did work originally but at some point Apple introduced double press the Home button which in our testing always gave the app less time to clean up.

In addition, the Springboard is a major feature in iOS so it is liable to change under the hood with every release from Apple.

Our Fix

Take less time. Thankfully it was pretty straightforward to do this.

1. Ensure the image and image view you are going to use are ready and loaded into memory before you need them in applicationWillResignActive. At this point our project started to behave but we chose in addition to use a smaller image to make an incremental saving in speed.
2. Dont use a massive image. The original image used in this project was 2.4MB which we reduced to 250k. At this point we were all pretty happy with the performance but it is possible to do something more if neccessary.
3. If you really want to make sure your app has enough time, don’t even use an image, just add a [black] view over the window.

Once we reduced the time it takes to obscure the app things started to look a lot rosier.

Summary

Dont assume that something that once worked is going to continue working forever.

Do test.

Test more than that.

________

Here is a github project with a working implementation of a lock screen. Feel free to have a look and use it if you want.

Developer: WhatTheWhat is Kerning?

There was a time when such conversations could lead to …

Kerning is the typographical adjustment of the space between character glyphs.

That sounds quite complex and guess what it can be. In the WAR image above the top line has no kerning, the middle line has ‘automatic’ kerning and the bottom line has ‘manual’ kerning; which means some glyphs are kern(ed) more than others.

Luckily, most of the time in app development (maybe in IT development?) when the designer mentions kerning, they probably mean tracking.

Tracking is a consistent spacing between a series of letters.

Confused?

In iOS with the introduction of the Attributed String we as developers can configure strings of text to easily achieve tracking and if a string really needs kerning we can do that too with a little more effort. Confusingly there is only one attribute to modify on an attributed string to achieve either kerning or tracking and that is:

NSAttributedStringKey.kern

Essentially, if you kern the whole of a string consistently then that is tracking; if you dig deep and kern different parts of the same string with different values for spacing then that is kerning.

UIKerningTextField

Repeat readers of my posts will recognise my affinity with customising UITextField. I’ve done it again! UIKerningTextField allows you to achieve tracking. Should it be called UITrackingTextField? Possibly. Here it is in action.

The top text field has no kerning applied. The middle text field has a -ve value applied, which draws the letters together. The bottom text field has a +ve kerning value which spaces the characters further apart.

Here is a gist for UIKerningTextField. As always, I reserve no rights to the techniques / code; just use as you will.

Footnote

If you really need to achieve kerning and not just tracking then you need to do more work and that exercise I leave to you dear reader…

Create Read Update Delete

Databases are essentially CRUD systems and when we as developers use them it’s a really good idea to know when a record in the database was created and when it was last updated.

Date Stamping

Say we have a member variable of a NSManagedObject, date_created and another member variable date_modified. We could, each time we change the object, also remember to change these two member variables accordingly.

This is nice and well meaning but each time we wish to update those variables we have to know, “Is it the first time?” and “Has anything actually changed?”. Suddenly our good intentions have brought us a host of work and maintaining the date stamps is starting to look painful.

Can all this date stamping malarky be done in an easier way? Of course it can! It can actually be done automatically and once you have set up your objects and date stamping code you can then forget about it until you need to examine those dates.

Data Model

First create your model. We will use SignatureManagedObject to help encapsulate our need for two date stamps.

Each object in your model that needs date stamps inherits from SignatureManagedObject.

I’m a simple guy so when I do this I make every object in my model inherit from SignatureManagedObject.

date_created and date_modified are of course Date types. Let’s check the identity inspector.

The Magic (Automation)

In SignatureManagedObject.swift add the sign() method.

Core Data Stack

Moving the Core Data Stack out of the AppDelegate is a topic for another post. For now we will adapt Apple’s current boiler plate code.

Now what happens when you call saveContext() is any new objects (those being inserted) are signed and any modified objects (those being updated) are signed.

Thanks for reading & good luck!

Thankfully those times are getting rarer and recently I had a lightbulb moment and suggested we use an Input Accessory View to facilitate text field choices for the user.

Input Accessory View’s are common place these days in iOS, here’s one for reference.

My problem was to show the user a list of previously entered email addresses in a UITextField.

Because device footprint is an absolute premium in mobile it’s often beneficial to take a moment during design or elaboration phases of work to think about how best to implement a UI Control so that it’s integration into a UI/UX flow is as seamless as possible.

UIAccessorizedTextField

UIAccessorizedTextField is a UITextField subclass which when tapped and the keyboard shows will add an Input Accessory View which contains a UICollectionView of Strings which the user can tap to choose. This is what it looks like in action.

Setting up a UITextField to behave as above is very easy.

Code

Here is the code in a gist. It’s all in one file for portability. Use it if you like. I retain no rights to the code you can just do as you wish.

If you liked this you may like:

Kerning — pardon?

or

NSManagedObject + Auto Date Stamping