The final day of NSConf 2012 started off with an inspiring talk by Fraser Speirs (@fraserspeirs) on the deployment of iPads throughout Cedars School of Excellence in Greenock near Glasgow. In 200, they gave every child in the school an iPad, since they are teaching the future citizens of the 22nd century whose lives are going to be even more integrated with technology by the time they graduate from university.
The example applications which he referred to in the presentation (Math Bingo, Brushes, Toon Tastic, iThoughtsHD) were good examples of applications which involve the children being creative (and not just learning for the sake of it). However, he made a few suggestions, such as Slice It! which he berated for getting too difficult too quickly.
The general advice applies to any app, not just ones geared towards children, included:
- Assume that the internet works correctly
- Assume the internet is fast
- Offer in-app purchases (which may be disabled by parental controls; test)
- Assume that the child can read (for early pre-schoolers)
- Assume that fine motor control is perfect
- Get difficult too soon
- Lock into a single cloud (e.g. only provide export of video via site)
- Offer too many export options (PDF export to WebDav/Email sufficient)
- Use notifications as advertising channels
- Assume everyone speaks with an American accent
- Encourage shaking of the device for a required operation
- Make sure adverts are age appropriate
- Be creepy with user data (including location)
- Crash – you get one (maybe two) chances
- Be fun
- Talk to teachers (especially with the recent changes)
- Test with children (your own, or ones you know!)
- Remember that there are different curricula (even within the UK)
- Be power efficient
- Prioritise stability over features
- Provide a guide for teachers/parents
- Support the ‘photos’ app as a shared filesystem
- Penalise random presses (to avoid guessing)
- Be ‘tamper evident’ (e.g. when the child quits without finishing)
- Provide structure and add headroom for creativity
- Record and play back user activity, especially via video if possible
- Consider localisation even if it is country specific
- Support projectors and AirPlay – an AppleTV is a cheap remote display
The last point – enabling a teacher to present from anywhere and show the display on the screen, or allowing a student to present their work on the shared screen, is going to really be powerful in the future.
The education market is ripe for a revolution of electronic applications (those that aren’t just PDFs in a single-purpose app – if you show a barcode, you’ve failed).
Niklas Saers (@niklassaers) Calabash is available from GitHub, and provides a testing framework for iOS and Android. It uses a cucumber test harness to run tests, and simulates user interaction gestures and can test the state of the user interface.
Since the test framework needs to use private APIs, the setup script generates another target which includes the test framework (but shouldn’t be used for submission to the app store).
The test framework was built by LessPainful, who have a way of testing the same application across multiple devices (including a robotic rotation device), and can run tests over those devices and report back screenshots where necessary. There’s an informative blog post discussing the calabash-ios framework. There’s also a number of wiki pages on the GitHub site.
Broad Decisions and Narrow Promises
Guy English (@gte) spoke about a game called “Poodle Pump” (though I can’t find any reference to a game by that on the app store). Other than a series of pump-related jokes the general gist of the presentation was that as an application evolves, it is necessary to determine the backward-compatible nature of the data used by the application.
The theme of the talk was that any promise to the user (whether it be an explicit one as part of the game’s documented feature set, or if it is an undocumented feature which becomes known) then this is something which ends up being a feature which needs to be supported. Guy suggested that this is why Apple keep APIs private for so long, so they’re explicitly documented as unpromised features. (HFS+ was used as an almost obsolete filesystem technology that Apple keep having to support because it is their main system.)
Robert LoBue (@roblobue) of AppLingua gave some very useful advice about app localisation. There are several reasons people choose to localise applications (increased downloads/sales or SEO purposes).
However, simply localising an app doesn’t necessarily guarantee any of those. Typically, any PR releases such as announcements and news items are needed in the main language, and the same is also true of any other languages. Generally, apps recommended on the ‘featured picked’ are translated into the loacl language.
There’s a lot of useful information on AppLingua’s knowledge base, including some links to useful applications used for translation and editing purposes. The suggestions are to translate the keywords, app description, in-app images and other user interface widgets. However, the “what’s new” or website are rarely things which need translation.
Some command line tools (such as
ibtool) can be used to
extract and convert strings into
statements in the code.
Finally, Rob cautioned against using Google translate, or any other automated service, for performing translation. Even Apple isn’t immune, having recently released images of iPhone 4S with iPhoto and having replaced ‘crop’ as a less palatable word on their display materials.
Core Data and iCloud
Sadly the presentation went about three times as fast as it needed to get the information across, but every third page was a facepalm with the statement “you can’t” – a recurring theme of the presentation.
One point of note was the cloudstorm that can occur when changing a
transient Core Data property when two or more devices share the data.
Since the changes don’t actually have any effect, the data is effectively
unchanged, but it does trigger an update (which then has the same zero-effect
update and causes a subsequent update). Avoiding transient properties should
fix that problem, as will launching with
-com.apple.coredata.ubiquity.logLevel 3 to get a spamfest in the message
log saying what Core Data and iCloud are doing. Allegedly implementing
+contextShouldIgnoreChangesFor<Key> allows you to determine if
the key should be ignored. This doesn’t appear to be documented anywhere,
although a brief use is mentioned in