I’ve been a bit quiet here lately – not a lot of interesting stuff coming across my desk, and a site release for the day job (which is only of interest to people who live 60’s music). And an Android app mostly finished. But it’s not THAT quiet:

Xamarin announce the Xamarin Developer Showdown.

What is it, you ask? Well, you write an app (iOS, Android, Windows Phone – I suspect serious bonus points for more than one of those), using Xamarin.Mobile, submit it to Xamarin, and you can win an iPad, Surface or Nexus 10. Sweet!

What is Xamarin.Mobie? It’s a cross platform abstraction of some of the common bits on the three platforms:

• Location / GPS
• Camera / Photos
• Contacts
• Compass and Calendar coming in the future.

It allows you to use consistent code to use these things, across the various platforms. The code is very .NET-focused, so you get nice stuff like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

var picker = new MediaPicker (this);

if (!picker.IsCameraAvailable || !picker.PhotosSupported)
{
  Toast.MakeText (this, "No photo for you", ToastLength.Short).Show (); 
  return;
}

picker.TakePhotoAsync (new StoreCameraMediaOptions
                       {
  Name = "foo.jpg"",
  Directory = "photos"
})
.ContinueWith (t =>
{
  if (t.IsCanceled)
      return;
  
  Bitmap b = BitmapFactory.DecodeFile (t.Result.Path);
  RunOnUiThread (() =>
  {
      imageView.SetBitmap(b);
      t.Result.Dispose ();
  });
});

Which will mostly work – almost unchanged – on all three platforms. Obviously, Toast isn’t going to work on iOS, but the TakePhotoAsync bits will. Xamarin.Mobile is free (tho not open source).

I’ve been using it on my current project (which is an Android one) and it’s very useful and very easy to use.

Go forth and create!

On a totally different topic, UX Magazine has a great distillation of the HIG, in the form of iPad User Experience Guidelines. Worth a read for all tablet devices I think, not just iPads.

Apple’s Human Interface Guidelines for the iPad outline how to create user interfaces optimized for the iPad device. According to Apple, the best iPad applications: downplay application UI so that the focus is on content; present content in beautiful, often realistic ways; and take full advantage of device capabilities to enable enhanced interaction.

Previously, I’ve discussed NFC a bit, and also Passbook. I’ve been thinking about the whole payment thing a bit lately, and I think I might have come up with something which might work – or at least be a starting point.

First up, I don’t see Passbook as a payment method. It’s a barcode, and as such, it can be easily copied. You can easily take a screenshot of a Starbucks pass, and scan it in Starbucks, charging your drink to someone else.

But in the same vein, I don’t see NFC being used in anger for a while. It’s too complex for most shops, and the merchants (ie, VISA, AMEX, the banks) are very slow to act.

So, a possible solution.

Assumptions

This is designed to work with – not replace – existing card terminals. It assumes that the user and the merchant both have internet, and the user has a smartphone.

Using it at the POS

1. A transaction is completed on the POS, as per normal.
2. The merchant enters the amount of the transaction into their “terminal”. This might be automated as part of the POS (eg, Vend, Lightspeed, Square) or it might be manually entered into a hand-held device using an app from the provider of this service.
3. The user then scans the merchant “code” (NFC, QR, barcode, or has a list of recently used places based on GPS). This code is unique for both the POS and the merchant, so if you had 3 POS terminals, they’d have 3 codes. The transaction value shows up on the screen, and the user accepts it, possibly picking which method to pay with and entering a pin if required.
4. The merchant’s terminal is notified that the transaction has been accepted (push message, web service etc). If needed, the users photograph could be provided for further verification.

This is a fairly simple flow. It would also support merchant-not-present transactions, eg:

1. The user completes an e-commerce transaction up until the payment steps, as normal.
2. The website pushes the value to the service, and shows the QR code/identifier on screen. This identifier would be unique to the transaction, not just the merchant.
3. The user scans the code, and the app connects to the backend service to retrieve the transaction.
4. The user accepts the amount, and the service notifies the merchant’s e-commerce application that it has worked.
5. Normal fulfilment happens after this.

Having this work from a Smartphone app would allow things like automatic loyalty cards, tabs (like Square), automatic “I’m near this merchant” type functions.

Backend

The backend of this service is where I think it can get interesting. Both the merchant and the user need to be signed up (as they do now with credit cards), and provide some way to pay, or to receive money (as they do with PayPal now).

Once signed up, anyone can receive or send money, and the backend service is responsible for pushing the money around. This might be direct to/from a bank account using a service like GoCardless or PayPal, a normal credit card merchant gateway, or a stored-value account, or any other payment method.

Not relying on a credit card gateway reduces the cost hugely.

Importantly, the user does not have their card details on their mobile device, and the merchant does not see or receive their card details. If the device is lost of stolen, the cards are protected by a PIN, and even if that pin is guessed, the device can be disabled, as it must communicate with the server for each transaction.

Functionally, this is quite similar to the Barclays PingIt service, which uses the mobile number as the unique key. It’s sender initiated, where as my method is merchant initiated.

Advantages

• More secure than a credit card, less impact if it’s lost or compromised.
• Two or more factor authentication should reduce fraud.
• Merchants could do this with an iPod Touch and a WIFI connection. That makes for a very cheap terminal.
• Could easily be integrated with a system like Square, where the card is present.
• Moo now supports NFC business cards, so with that and a QR code printed on it, you could use your business card as a payment receipt method.
• Easy to setup without a merchant account. Cheap service to run.
• Multiple sources of money: Bank account; Credit/Debit card; Paypal; Balance.

Problems

• Chargebacks for credit cards could hurt a lot. I’m not sure how PayPal deals with this.
• Scanning bar codes is a pain in the arse. That said, chip and pin is almost as bad.
• Requires a smartphone with a decent camera. Requires an internet connection (fine in cities, not good in rural areas)
• Doing a bank transfer transaction without having the money to back it up. Could be fixed with a credit card being required, but direct debit and other methods are not real time.
• Fraud; Money Laundering.

This is mostly a brain dump, but what are your thoughts on it? Did I miss something big somewhere in the process?

Things like this make me love Dribbble.

I want to encourage some good App.net apps.

Here’s a bunch of images as a starter kit. If you do something interesting with them and need some more, please get in touch (I don’t have that much spare time, but you never know).

Dribbble is a community for designers, to allow them to show of what they are working on. Usually, it’s a small bitmap (400x400), but they can attach larger images or other files if needed. The small size makes it easy to show something, without giving away what they are doing on a sensitive project.

There is also the concept of a rebound, where someone else can take the design and rework it, and have a proper discovery of “this is a rework of that, what do you think?”.

As a non-designer, I can’t sign up (well, I can, but there’d be no point). But I can register as a viewer. I wish I could comment, but I’ll settle for “liking” stuff.

I follow (and it pops up in Google Reader via RSS) some of the FreeAgent people (Chris, Roan, Robbie), Phil from Xero, and various other people.

Thanks, Marc from Bjango. Posting stuff like this is great for inspiration.

—

So. The new iPad Mini is out (kinda).

• I like the idea of the size, but I want to try one before buying it (as a replacement for my iPad2). I have a bit of trouble seeing smaller text on the Nexus 7 screen, and as I use my iPad a lot more than any other device, I need to be able to read it easily.
• They kept the 1024x768 screen resolution. Thank you, Apple.
• As Nathan pointed out to me, this is going to ROCK for schools and early childhood education. It’s smaller, for small hands. It’s cheaper (the price in NZ is better than the price in the UK), but it still packs a huge amount of power.

It’s still too expensive to be a definitive game changer, but it’s a long way towards that.

The 13” Retina Macbook Pro looks interesting, too. I’ve had a few 13” MBP’s in the past, and it’s always been my favourite size for a laptop – except the tiny screen resolution. The Air mostly fixed that, and this does so even more. 1680 wide on a 13” screen is a sweet spot for me, but having just bought a 15” rMBP, I’m not going to be upgrading for a few years.

And who knows what Apple will have then.

—

@GregMunn on the Xamarin Forums asked how to discover what UIAppearance properties a class has. After a bit of a google around, its quite easy:

1
2
3

cd /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/

grep -H UI_APPEARANCE_SELECTOR ./* | sed 's/ __OSX_AVAILABLE_STARTING(__MAC_NA,__IPHONE_5_0) UI_APPEARANCE_SELECTOR;//'

This shows all properties which have UI_APPEARANCE_SELECTOR in them, which are the ones you can customise. Sadly, the one he wanted (UITextField) doesn’t.

I’ve been trying to follow all the slides and presentations at this years MonkeySpace aka the conference formally known as MonoSpace.

Looks like the content has been really good. Here’s some of the deck’s I’ve been able to track down so far:

• ChrisNTR – iOS6 – slides / code
• David Fowler – SignalR slides / code
• John Zablocki – TouchDB for Mono – code
• Greg Shackles – Cross platform mobile – slides / code
• Paul Betts – Async call to arms – slides
• Somya Jain – Going Mobile – code
• Demis Bellot – Service Stack – slides
• Aaron Bockover – Vernacular – code
• Jonathan Chambers – Embedding Mono – slides

A few I’m missing that I’d love to see links to:

• Miguel de Icaza – State of Mono
• Michael Hutchinson – Mono Develop, I suspect
• Frank Krueger – Rapid development
• Sam Lippert – MonoCross
• and a lots of others.

I think the organisers are planning on linking to them all once it’s all over – and possibly putting video up, too. Cross fingers :)

Android Niceties is a showcase of Android design, and I’m finding it great to get some inspiration for what is possible in Android.

Interestingly, Xero (which is not a native app) is featured at the top. It is a nice looking app tho.

The Android UX is the main part I have a love-hate relationship with. Holo goes a long way to making it nice, but drop back to 2.2 or 2.3, and my eyes are bleeding. Scrolling of lists is a big part of it, because lists are such a huge part of most mobile apps.

Unsurprisingly, this is mostly Holo themed, and I’d assume they are using the likes of ActionBarSherlock and the various other bits that make Android mostly standard from 2.2 to 4.2.

I have a love-hate relationship with Android (and by extension, Mono for Android). I’ve been a long-time iOS user, and back in the Android 2.x days, the difference was huge – in my mind, there was zero comparison. One was polished, fluid, beautiful. And the other one really, really wasn’t.

Having to spend £500 for another phone just to play around with it made it a non-starter.

I tried out Mono for Android about 2 years ago (it’s a long time since we had the 3 months in New Zealand!), and while the product itself was good (even for a then-late beta), I didn’t have a device, so I was stick in the emulator.

One thing to know here is that on Android (and Windows Phone 7), the on-computer “thing” is an emulator, which means it’s running ARM code on your x86 (or x64) machine. This is slow, and always will be slow, there is no way around it. And the Android one was dog slow at the best of times, even on what was at that time a very fast machine.

iOS, by comparison, is a simulator. It’s not running ARM code, with stubs for the bits of phone that are not present on the computer (eg GPS). It’s running native x86 code, so that whole emulation layer is removed, and the speed difference is astonishing.

On iOS, you need to test on the device because the simulator can be a lot quicker than a real device (not so much now with the 4/4S/5). On Android, you have to test on a real device because the emulator is so slow it’s nearly unusable.

However, I’ve been doing a bit of (Mono for) Android work over the past week or 2, using a real device (Nexus 7 and a Samsung Ace). So far, I’m finding it quite good. The API and its structure is very different to iOS, even tho the resulting apps often look similar. OS version fragmentation freaks me out, however, as I only have these two devices to test on.

So I went back to the emulator. Luckly, a lot has changed in 2 years, and I spotted Willem Meints post on getting the x86 emulator working.

In the post, he details how to setup a new emulator. I had to also download the image from google, which isn’t hard, but if you only have Mono for Android installed, with it’s self-contained Android SDK, it’s not obvious:

1
2

# cd Library/Developer/Xamarin/android-sdk-mac_x86/tools
# ./android

Then find and install the x86 images you want. I got 2.3 and 4.0.3.

Now, to get it working on the Macbook Pro retina display….

Update: Roan at FreeAgent has put a post up about it.

Last night at The Herald Digital Business Awards, Earnest won in the Best Application category!

@kevinjmccallum: Delighted to report @freeagent wins best mobile app at @HSDigitalAwards for Earnest. Nicely done! Image

To be honest, I wasn’t even aware the app was nominated! Nice work, and congratulations to the FreeAgent team – Roan and Robbie. Earnest was fun to work on – and the guys from FreeAgent fun to work with – so I’m quite chuffed with this.

This is a question I’ve wondered about a fair bit, especially as I like everything to be digital, and mobileAgent is a great way to get your receipts into FreeAgent, digitally. The fine folks over at ReceiptBank have the answer

So we thought we’d share what HMRC say on the matter:

“Records may be preserved on optical imaging systems, and the originals discarded, provided that what is retained in digital form represents a complete and unaltered image of the underlying paper document.”

If you’d like to find the exact text here’s the HMRC document. They’ve also reiterated this point in various other documents.

So, while you still need to keep the files for 7 years (yes, really), keeping them as digital versions is quite acceptable, which reduces the amount of paper you have to have lying around! Win!

Incase you didn’t know, in mobileAgent you have various choices for your receipt images.

You can take a photo, and attach it to an Expense or Mileage entry, using Add Expense or Add Mileage on the home screen. When the item is uploaded, this is automatically attached in FreeAgent.

If you turn it on in settings, you can also save these images in Dropbox or the phone’s Photo Library.

You can take a photo as a receipt, using Add Receipt. This is designed for things you spend on your company card, as opposed to an expense which is spent on your personal card and claimed back from the company later.

As FreeAgent doesn’t have anywhere to store these, they are normally uploaded to Dropbox, but if the “Save to photo library” option is enabled, then they are saved there, too. Receipts will upload to Dropbox if it’s linked, regardless of the “Save to Dropbox” setting. You can also email receipts to yourself when you enter them.

The “Save to Dropbox / Save to Photo Library” is mostly for people who either want a backup of their expense/mileage receipts, or need some way to bulk-send them to their accountant, without going through each item in FreeAgent and saving them off.

The fine folks over at BillGuard have a long post all about their implementation of Passbook, and some of the pitfalls.

For the sake of those of you that decided to join in on the Passbook party and create your own passes we present here some of the pitfalls we ran into. As with every new and fangled thing, Passbook is still rough around the edges and surely you’d rather work on actual features and reduce the time spent on just getting the damn thing to work, right?

This is a nice, detailed post at a developer level, not a business level. Worth a read if you want to make passes.

Passbook is a new “app” from Apple, which comes with iOS6. Having just listened to the latest In Beta, and various other bits around the web, there appears to be a lot of confusion about what it is, and how it works.

I’ve had a bit of a play with Passbook and PassKit (the API’s behind it), and a cursory glance at Google Wallet, and here’s my thoughts and (hopefully) some clarification on what it is, and what it isn’t.

Background

First up, we are talking about two distinct things here.

NFC – Near Field Communications

Google Wallet is NFC based. This means there is a small radio in your phone, which is activated when it comes in contact with a reader (which provides the power via induction, same way an electric toothbrush recharges). This activates the chip, which it communicates with.

Depending on the chip, it may just allow itself to be read, or it may allow something to be written to it. This would be encrypted with the source’s keys, so it can verify that whats on the card wasn’t put there by someone else.

It may even run a small application to verify the reader. Each card has more the one slot, so you can store a travel card and a balance on the same card. There are lots of options depends on the requirements.

Other examples of this are the “prox-cards” that a lot of businesses use to let people into doors, which are usually read-only at the door, or the travel cards in places like London (the Oyster card), which are read-write at the barrier gate. “Tap to pay” credit cards use the same system (read only).

In this system, the card is somewhat intelligent, and getting something useful onto the card (eg, my Oyster info, or my Debit Card details) requires things to be signed before they are written, so that I can’t just “borrow” someone’s card and load it onto a blank card or my phone, or add more credit to my Oyster card. Often, there is code running on the card – usually some flavour of Java – so what they can do is quite advanced.

Having one of these on your phone means that you have a chip – similar to what is in your NFC-enabled debit card – which can be read like normal, and the phone also has a writer which can be accessed via the phone’s OS. Usually, these are independent – if your phone is out of battery, it may still be possible to read the chip, as enough power is being provided to the chip from the card reader. But usually, you’ll pick a default card (which is always written to the chip), and maybe select another card for one-off use. This is written to the card, read by the reader, then the default is put back on.

Bottom line: the card is the source of truth, or a verified copy of the truth in the case of a credit card. It holds my travel card (and balance), a credit card number, or a cryptographic key or program which lets me do something. It can’t (easily) be cloned without the private keys.

Note that if you ignore the cryptography part, writing to a NFC chip is easy. But if it’s going to be useful, the data you write has to be signed by someone, and that someone has to be willing to do it.

(for the pedantic, I suspect the technology in a building access card is not true NFC, but the concept holds)

Barcodes

Passbook – and the million other things with a barcode on them – works in a totally different way. The barcode has a unique number which means something to whoever is reading it, but it is not globally unique. It’s passive, meaning it doesn’t have any intelligence or smarts, and no power is involved.

This can include:

• Normal barcodes, which are on everything. They can usually store 13-15 digits, and can be read with a single laser
• 2D barcodes, like QR codes, PDF417, Aztec and various others. These are the same idea as a normal barcode, but can hold a lot more information – 1024 bytes or more. They require an optical reader, which takes a photo of the barcode and works out the data from there.
• Magnetic strips, like the back of every credit card. This has more info than a barcode, but not a lot – maybe 64 characters, over two tracks.

Normal barcodes are trivial to copy – just use a photocopier. 2D barcodes are a little harder, but only because they are more detailed. Magstripes need a special writer, but these are easy to get.

The important part is: There is no logic on the card. An active reader (ANY active reader) reads the card, and it’s the readers job to do something with it. This might be taking the number and looking you up in a customer database when you are at the gym, or passing your credit card number and name to a credit card processor.

This is where Passbook comes in.

So, what IS Passbook (and what isn’t it)?

Passbook (the App / technology) and PassKit (the API) only work with barcodes, specifically 2D barcodes. The user acquires a Pass somehow (more on that in a moment), and they present it to the vender who does something with it.

Thats it. But it’s what Passbook does on the phone thats interesting.

You can get passes a number of ways – and I think this is whats confusing people:

• You can download one of the apps, and the app, using PassKit, can build and load a pass into your phone. The Airbnb, Eventbrite, Starbucks and American Airlines apps is a prime example of this. This is useful for airlines, as they can generate (securely) a boarding pass, and load that in, based on your authenticated flight details.
• You can download one using Safari or from an email attachment. It’s just a zip file, with specific content. Sites like Passk.it enable that, and there is .NET code to generate them.
• Most likely there are other ways. Eventbright even have a reader app for this. Full circle!

Inside the Pass – it’s just a zip file – is various information, including:

• Urls to connect back to the source service to request updates or a new pass, and where to register a pass and the push notifications keys.
• Branding information.
• One or more geo-locations, which is useful for the “you are near Bikram Yoga Chiswick” pop up thing, so you don’t have to find your pass. It can also pop up based on date.
• It’s all cryptographically signed, so without the right keys (which the creator has) it will not work. I can’t make a pass for Starbucks with someone else’s details, even if I know their card number. It has to be signed by Starbucks.

Apple has a whole site up on the developer portal for this. There is code on GitHub, too, in various languages, and Xamarin have docs on how to do a lot of this in MonoTouch. There is a bit of fun around signing the passes, but there are lots of examples, and otherwise, it’s quite easy.

Once a pass is scanned, and the receiver (Starbucks, your gym) processes your details, they can use the normal Apple Push Notifications to tell your pass to update itself. This might send down a new pass, or it might just update some info (eg how many visits you have left). It’s up to the pass and the source server.

You can create various types of pass, but really, they are all have the same content – branding, a barcode – the difference is in the expected use:

• Store cards. May have stored value (on the server, not in Passbook), or might just be to identify you.
• Boarding passes and tickets. The person letting you in must scan and validate it.
• Vouchers (the barcode would have to be verified, or it expires after a given date, but can be used up until then)

So, Passbook is a sort of hybrid of some of the intelligence of NFC – auto updating for example – with the easy-to-integrate dumbness of a simple barcode. It’s not, in ANY WAY, designed to replace your credit card or travel card. It’s designed for the situation where the receiver validates the information, not where the card is the “one true source” of information.

Here’s some uses, around London, that I think Passbook would work great for

• A loyalty card for a cafe. They could use an iPhone to scan the pass, and push to a shared cloud server, which pushes out the number of coffee’s you have had. Hooking it up to a system like Vend would be great, as it could interact with the POS.
• Replace my gym card; My work ID card (which has no intelligence); A video store card (they still exist?); My Bikram Yoga Chiswick card (which is just a barcode). Basically, anything with a barcode. Only downside is that most places that use these have the old single-laser scanners, which do NOT work on a smartphone screen.
• Tickets to get into things: movies; museums; concerts; airplanes.
• Discount coupons (one use or time based): £5 off when you spend £15 at a restaurant.

It has lots of uses, and I’m sure that smart people will come up with more, but it requires a bit of back-end integration. NFC is usually already integrated into things which require a good amount of security, and that also makes NFC difficult, as the provider – Visa, a bank, Transport for London – needs to get onboard to allow their card info to be loaded onto a phone’s chip.

To be honest, I’m not sure NFC is going to take off any time soon. It’s overly complex and requires forward thinking from parties – mostly banks – who are usually technologically backward and conservative to the point of paranoia.

Passbook might take off, especially if someone comes up with a nice backend for small businesses to easily do loyalty stuff (yes, I’ve been planning on doing this, feel free to steal the idea tho), and slightly larger businesses to just replace old barcode scanners with more expensive 2D scanners, and the leverage their existing systems.

Is it all a huge game changer? No, I don’t think it is. But like the AppleTV, it is interesting and fun to play with.