Colin's Journal: A place for thoughts about politics, software, and daily life.
October 4th, 2015
HTTP Push Notfications
Arran Beach
Owlauth allows users to register a device (e.g. a phone) and then use this device to confirm their identify when logging into a website or application. For this to work the Owlauth app running on the phone needs to be able to receive push notifications of authentication requests. There are many centralised ways to push notifications to a phone, but as each domain owner can run their own Owlauth server, a centralised solution isn’t a good fit.
By taking advantage of Go’s cheap handling of concurrent processing with Goroutines, a simple HTTP based push approach can be used. Clients connect to the server:
- Passing a Bearer token that authorizes them as a registered device.
- Passing an If-None-Match ETag if it has one.
- The HTTP GET then blocks until either:
- The HTTP Keep Alive timeout is approaching – in which case the server returns nothing.
- A new authentication request is available or an existing request goes away.
- When the GET returns, an ETag header reflecting the current state.
- The client loops, issuing a new HTTP GET request with the latest ETag.
The server returns before the Keep Alive timeout, which means that the client will reuse the same TCP (and SSL) session as for the first request. This makes this timeout and GET operation an effective ping that proves the connection is still established. If the TCP connection becomes invalid, the client’s HTTP library will open a new connection to the server, giving the desired reconnect behaviour.
The server implementation in Go is straightforward:
var requestedEtag string
requestedEtag = r.Header.Get("If-None-Match")
authChannel := reqStore.RegisterListener(dev.DeviceOwner)
defer reqStore.UnregisterListener(dev.DeviceOwner, authChannel)
clientGone := w.(http.CloseNotifier).CloseNotify()
var request *reqdb.PendingRequests
timeout := time.NewTimer(DeviceRequestGetTimeout)
for {
select {
case req := <-authChannel:
if req.GetEtag() != requestedEtag {
request = &req
// Return the ETag
w.Header().Add("ETag", req.GetEtag())
return request, nil
}
// Just loop and try again.
case <-clientGone:
// Nothing to be done - just return
log.Printf("Device gone - returning\n")
w.Header().Add("ETag", requestedEtag)
return nil, nil
case <-timeout.C:
log.Printf("Device request get timeout reached.\n")
w.Header().Add("ETag", requestedEtag)
return nil, nil
}
}
The reqStore object keeps track of outstanding authorisation requests and provides the details on a channel to all registered clients that are sat waiting in this GET.
The only other element of the equation on the client side is adopting a suitable retry strategy when http connections are not working. For desktops that could be just a simple back-off to a few seconds sleep. For the Android client it needs to taken into account the current network state to avoid excessive battery drain.
I’ve now got a basic version of this working on my phone. I’ll run it for a while and see how much battery impact it has.
May 5th, 2013
SwiftKey and trailing spaces
During testing of the latest version of ExpenseClam (released just last week), I stumbled across a small issue that I’ve not seen before.
Until recently I was using a back port of the Jelly Bean keyboard on my phone. I really like the swiping of characters implementation and find the auto correct to be rather good, although the prediction is rather limited.
Since SwiftKey released their version of character swiping (called SwiftKey Flow), I’ve been using it on my phone, and it’s generally good enough that I’ve not switched back to the Jelly Bean keyboard.
Now on to the issue: trailing spaces. Having swiped across letters to form a word, SwiftKey populates the word, and adds a space ready for entering the next word. Unfortunately this space isn’t just for show, it is populated in the widget value, so when the contents of the field are saved it includes the trailing space.
In general this is mostly harmless, however if you spot the trailing space and delete it, you can end up with two database records that look the same, but are actually different. This makes auto complete on fields less useful and potentially confusing.
The fix is easy enough, I just trim the string before saving to the database, but it would have been better if SwiftKey had used the same approach as Google and inserted the space at the start of a swipe rather than at the end.
April 8th, 2012
Blackberry Playbook
I’ve recently acquired a blackberry playbook by porting ExpenseClam to this platform. The physical format of a 7 inch tablet seems to work very well. It is still small enough that carrying the device around is very easy, and holding it in one hand is entirely comfortable. Meanwhile the screen is just large enough that websites can be viewed in their desktop format, without having to zoom in and scroll.
That’s the good news. The bad news is that the quality of available apps is very low. Most of the big name apps are missing (e.g. no Skype). There are many ported Android apps, but these work only partially. Native Android features are missing and they have a tenancy to hang.
Native apps that I have found suffer from a clunky keyboard implementation, and flaky UI widgets. The Web browser is reasonable, but occasionally suffers from unresponsive UI elements.
My overall impression is that the tablet would be far more useful and interesting if it was running Android ice cream sandwich. This leaves me wondering whether I want to get either a 10 inch tablet our something around the 7 inch mark.
To sum up: when writing this post, I started on the tablet, but the application hung, and I ended up retyping it on my phone. It is hard to see the playbook platform being a success given it’s current state.
January 5th, 2012
App rankings in the Android market
For an app that only recently moved into the 100-500 downloads range, the paid version of ExpenseClam is doing remarkably well. As of writing this, ExpenseClam is number 65 on the list of top grossing apps in the Business category on the Android market.
Looking at the next lower ranked app however I think this is down to how the market treats apps that change categories. Number 66 is an app called SMS super faker, which appears to have always cost the same as ExpenseClam, but is in the 1,000-5,000 download range. According to AppBrain it switched from the Communication to the Business category on the 23rd of December 2010, 6 days before reaching the 1,000 downloads mark. The only explanation I can think of for having a lower gross revenue than ExpenseClam is that it has had far fewer downloads in its new category than previously.
Similarly number 70 (calendar scroll widget agenda) also has far more downloads than ExpenseClam, but has recently changed category.
The lesson to learn from this appears to be that changing category within the market is penalised, at least as far as the top grossing lists are concerned. Whether this impacts app exposure is another matter. How many apps are purchased as a result of browsing the lower echelons of the top grossing list, versus searching and picking from the featured and staff choices lists is unknown.
January 1st, 2012
Tablet versus NetBook
I’m struggling to decide on whether a NetBook or a tablet would be better suited for me. The tablet would be an Android one, probably the new transformer prime from Asus. It would allow me to test tablet specific designs for ExpenseClam and would provide a more convenient form factor for web browsing than my phone. The transformer also has a keyboard attachment, so writing blog posts and even some web site design should be easy.
A NetBook on the other hand would allow me to do Android development while travelling, and even at home on the sofa, rather than isolating myself away in the study.
In theory I could use VNC, or some other remote desktop software to control my desktop from a tablet, but in practise I expect this to be clunky at best. I could get both a tablet and a NetBook, however I know that when travelling I would only want to carry one, not two machines with me.
At the moment I’m leaning towards the tablet. While ExpenseClam works fine on tablets, it uses the same layout as for phones. I should be able to design a layout that really takes advantage of the extra screen space available on tablets. It also feels like a more modern investment than what is essentially a small laptop.
This post is a bit of an experiment as it had all been written on my phone using the latest WordPress app. Overall not a bad experience, mainly thanks to the Swype keyboard.
September 7th, 2011
Android Market Experience
The Android Market continues to struggle in providing a great end user experience. To illustrate, here’s what I went through when purchasing Carcassonne tonight:
Dolomites looking desolate
- I had bookmarked the Carcassonne page on the market a few weeks ago, so when I decided to buy it, I followed the bookmark. The advertised price was £1.75.
- I clicked on purchase, and the site prompted me to login, which I did. The “review your purchase” pop-up appeared, but listed the price as €1.99, and was missing the Confirm button.
- Deciding that the phone version may work better, I searched on my phone for Carcassone, and saw the price listed as £3.49.
- Thinking that a lower price sounded better, I tried various re-loads of the page in my browser with no luck – the “review your purchase” pop-up grew a “Confirm” button, but it was greyed out and would not work.
- I tried searching in the web based version of the market for Carcassone. The result was a listed price of £3.49.
- Giving it one last go, I followed the search result link, and it brought up the page showing the price as £1.75.
- Selecting purchase I was shown the confirmation dialog with a price of €1.99, and a working “Confirm” button.
- Upon clicking Confirm the app started downloading on my phone – and the website showed a confirmation that I had purchased the game for £1.75.
- Finally my Google Checkout receipt arrived, showing the actual transaction cost €1.99
It’s fairly amazing that my own app (ExpenseClam) receives any purchases at all given the difficulty involved!
I should add that it was worth persevering – the game is rather good!
June 20th, 2011
ExpenseClam – finding the currency
Stair case
Yesterday I released ExpeneseClam, a business expenses tracking app for Android. Recording expenses on a smartphone can be a painful experience, typos are common, expense claims are not always made in chronological order, and there is usually little time to note down how much a taxi cost. ExpenseClam has a number of features to help make this easier. Simple things like auto-suggesting expense descriptions based on the amount entered can make it much quicker to record common recurring expenses.
One of the niftiest features in ExpenseClam is something that you will only stumble across if you travel a lot: it auto selects the default currency for a new expense based on the country you are in. This is done without needing user permission to determine location, carry out reverse geocoding or even internet access.
The secret sauce is Android’s TelephonyManager and it’s method getNetworkCountryIso(). This method returns the ISO code given by the mobile operator for the network that you are connected to (the Mobile Country Code). From this a Locale object can be created, which then allows the Currency instance to be created. None of this requires network traffic and it takes very little processing power to complete.
Changes in the default currency only happens when the country changes. This is to avoid frustrating users who have to enter expenses in a different currency to this default. The country derived currency is however prioritised in the list of currencies to make selection easier for what is likely to be a common choice.
February 13th, 2011
Android a challenge to OEMs?
Does the “Android Monopoly” really provide a challenge to the traditional OEMs? Is the answer to use virtualisation on the handset and put Android in a virtual machine sandbox while the OEM’s own O/S runs underneath it? That’s Andreas Constantinou’s proposal in his latest blog post at VisionMobile. I’m not so sure. Firstly let’s take a brief look at the history of the OEMs he identifies as losing out due to the success of Android: Motorola and Sony Ericsson.
Toronto sunset at the beaches
Motorola’s success story pre-Android was the Razr. This was a huge phone in 2005 and dragged Motorola into second place behind Nokia. The success of the Razr had little to do with the software that it ran, and a lot to do with the very distinctive and stylish design. Motorola failed to innovate effectively off the back of this however, resulting in a whole series of similar phones and declining market share. It is only with their adoption of Android that Motorola has been able to rescue themselves from terminal decline in the mobile market. The Droid series of phones built for Verizon have been very successful for them, bringing the company (now split off as Motorola Mobility) back from the brink.
Sony Ericsson’s history contains more highlights than Motorola’s, but is also a mixed record. They have used a number of operating systems over the years, with Symbian (using the UIQ interface) and Windows Mobile both playing a part. Sony Ericsson has been able to differentiate with their Walkman and Cyber-shot brands, both of which relied more on innovation in hardware than software. Sony Ericsson have produced a range of Android smart phones, which has done much to restore their financial health (to the tune of €1.1bn).
Hardware has always been a major differentiator between mobile OEMs, marking a significant difference between the mobile and personal computing industry. This traditional strength is not undermined by Google being the driving force behind Android. OEMs adopting Android get for free the things they have traditionally struggled with: a best-in-class smart phone O/S, app store and cloud services. This allows them to focus on the part of the equation where they have seen past successes and that aligns to their core competencies.
The announcements coming out of Mobile World Congress this year (and CES before it) shows that there is plenty of room for innovation in hardware and software:
- Sony Ericsson offering the Xperia Play. This shows that both hardware innovation (slide out game control pad) can be done alongside corresponding software innovation that sits on-top of Android (the PlayStation Store).
- Motorola announced the Atrix. This again shows innovation in both hardware and software, with a docking station that provides a desktop experience when the phone is plugged in.
- The LG Optimus 3D provides both 3D capture through dual cameras, but also a 3D stereoscopic screen.
- Samsung are generally sticking with a tried and tested form factor, but are innovating with the screen, the thickness of the phone and the inclusion of NFC in the Galaxy 2.
If Google is restricting what OEMs can do on the hardware and software front, I don’t see much evidence of it in the products that they are announcing, or an opportunity to do more by using virtualisation.
August 31st, 2010
Publishing to the Android Market
Stonehenge
Two weeks ago I published my first application to the Android Market. LibraryThingScanner is an extremely simple application that speeds up adding books to LibraryThing. The app launches the Barcode Scanner application to scan the ISBN, followed by the web browser to bring up the relevant LibraryThing search page. The app does so little I’ve been in two minds as to whether it was worth publishing at all, especially as the LibraryThing website does not work particularly well on an Android phone (for example continuously popping up the virtual keyboard).
Once I’d coughed up the required $25 for the privilege of publishing to the market I found the process very straight forward. There are certainly some quirks, such as being able to upload two screen shots or no screen shots, but the level of information required was very low. It’s peculiar that I find uploading my software to the internet at large, with a potential audience of nearly two billion people, a minor step, whereas publishing onto the market felt like a more significant thing, despite the comparatively small potential audience of a few million.
I’m glad that I did take the plunge. There was an initial spike in downloads as soon as I published the application, reaching 126 downloads and 97 active installs in a matter of a few hours. Since then things have levelled off and the application is averaging 17 new active installs per day out of 35 new downloads. I don’t know how accurate the statistics are for Android market application installs, but they are much more useful than any number of downloads for other software I’ve published online.
Seeing the number of active installs slowly creeping up, seeing the ratings (very slowly) coming in and now receiving my first comment (thankfully positive) makes the feedback loop from users much more satisfying than the very occasional email I receive regarding my other software. It’ll be interesting to see how things carry on longer term and what kind of reaction anything else I may publish receives.
June 15th, 2010
It’s not fragmentation – it’s progress
There have been a lot of articles recently accusing Google of dropping the ball with Android by creating “fragmentation” within the Android platform. This references either the number of base O/S versions (currently three versions make up 99.5% of active Android phones) or the fact that HTC, Motorola, Sony and others often put some of their own software on top of Android.
Yorkshire Windmill
This trend of complaining about fragmentation has now extended as far as complaining about the iPhone OS (recently re-branded as iOS). This new complaint is that Apple has also somehow fragmented their platform by introducing new devices with different hardware capabilities, in particular screen resolutions and densities (think iPad versus iPhone 4).
While it makes developer’s lives easier to have a single hardware platform to target, it’s also something that we are not used to. From the earliest days of home computers there has been a huge variety of hardware and software to contend with. Today’s desktop landscape is no different – developers need to decide which basic platform (Windows, MacOS, Linux) and what versions (Windows XP, Vista, 7?) of those platforms they are willing to support.
The development of larger and higher resolution screens isn’t fragmentation – it’s progress. The Android platform provides a set of easy to use mechanisms that mostly make the extra size and screen density transparent to the developer. Similarly the SDK makes it easy to know when you are using a feature that does not exist on earlier versions of the platform. You can then either make it optional, or if you truly need such a feature, drop support for older phones and be glad that Google’s rapid pace of development makes your application possible at all.
When considering the mobile application environment today I think there are far more pressing issues than additional phone screen sizes to be concerned about. The 30% cut that Apple and Google take from every application sold, Apple’s active censorship of artists and arbitrary banning of applications are far bigger and more pressing issues.
Software
The full list of my published Software
Email: colin at owlfish.com