Continue reading »]]> Yes, sounds surprising doesn’t it? Message Manager needs a number of wizards to ensure that the user experience for this potentially complex application is good. Android 4.1 still doesn’t deliver the goods, and neither does my other staple for Android – the excellent Action Bar Sherlock.

(rolls up sleeves)

Right, well, better put one together then.

So I’ve ended up rolling my own framework. No, it isn’t finished yet and is too intertwined with the Message Manager code – and my other framework code – to be thrust on an unsuspecting Android community. I hope to make it available by the end of the year.

So what do I want out of a wizard framework? I want something with a good clean lifecycle for setting up at the start of the wizard and completing it cleanly. I want a clean API within a wizard step for things like populating the view from an abstract data source, validating, and providing trigger points to do things when moving between steps.  Something that presents an uncomplicated user interface with various navigation options.

After some thought I started from an ActionBarSherlock sample – specifically the “Tabs and Pager” sample you’ll find in the fragments sample app. Viewing each wizard step as a tab has a number of immediate advantages:

• Navigation by swiping or by clicking a tab
• Visibility of what steps are coming up next

Of course its easy to add buttons to the bottom of each tab providing a third way of navigating.

Now in my app I’m quite happy to allow people to move between tabs in any order at all and only apply validation when they click the “finish” button. But this can be easily disabled by ignoring clicks on the tabs – or hiding them entirely.

One of the advantages I didn’t see coming when I started coding though was that each wizard step ends up being entirely independent of its siblings. This turns out to be fantastically useful when I have three wizards (create profile, create rule, create profile and rule) because it is trivial to re-use wizards steps from one wizard in another one.

Finally, implementing a wizard in this way means that it is now trivial to put together my application’s help and getting started activities.

On a technical level the wizard framework uses a ViewPager and FragmentPagerAdapter at the centre of the owning wizard activity. Each wizard step is implemented as a fragment which at runtime gets attached to a tab in the view pager. The wizard activity is given its steps as a simple array of wizard step fragments and uses this to set up the ViewPager. The only complication is that fragments can get housekept even while the activity is running so you have to be careful to ensure that the (potentially modified) state in a fragment is preserved in some way when moving to another step.

Continue reading »]]> Over the last few months we’ve been playing with a new application concept and are able to announce that we will soon be launching a new Android application and cloud service which we are developing under the working title of “Message Manager”.

Message Manager in its early from will allow you to selectively forward SMS messages (as an SMS or using email) and/or automatically respond with a canned message to the sender. You’ll be able to define which messages should be forwarded or replied to using a selection of criteria such as the sender, message text and when the message was sent (or received).

The application will then be built out to add full SMS client functionality that will integrate with a cloud service to allow you to use Message Manager on any Android device to read and respond to SMS messages on your phone(s) wherever they are in the world – they just need to be switched on and have data and network access.

We’ll be providing a web site for access from non-Android devices and our own SMS gateway to help you save money when sending text messages when you go abroad or have reached your carrier’s limit.

If that isn’t enough, the cloud service will act as a full backup of all your SMS messaging, so you can move your SIM card from phone to phone and not have to worry about losing important messages or ongoing conversations.

Message Manager will be free of charge and without adverts. Pricing for the cloud based services has not been announced but at least some of the services mentioned above will also be free.

Continue reading »]]> In August and September we had some issues with the newer multicore phones running Android 4.0 and up,  responding with a series of five point releases (3.4.1 through 3.4.5) which brings us to the point where Audio Clock is now behaving itself again on all platforms.

Going forward we have stopped adding new features to Audio Clock for Gingerbread (Android 2.3) but will still fix any problems that are reported to us; new features will continue to appear over time if you have a device running Ice Cream Sandwich (Android 4.0) or Jellybean (Android 4.1).

Or next planned big change to Audio Clock is to refresh the user interface so that it looks, and works, as an Android 4.0 application should, and we aim to get this into the Play Store before the end of the year. If that sounds like a lot of time for a small amount of work – you’ll understand why if you read some of our other announcements.

Continue reading »]]> Yesterday I was at the monthly meeting of the Groovy and Grails User Group at Skills Matter to hear about the recent release of Groovy 2 and a standard event bus for Grails applications. The evening was split into two sessions – the first on Groovy 2 and the second on a new Grails event bus.

First up was Peter Ledbrook discussing Groovy 2. There are a number of interesting features but the two that stand out for me are static type checking and static compilation.

Static type checking gives you real-time syntax checking in your favourite IDE (and by extrapolation, compilation errors when you build). There is a trade-off – you lose most of Groovy’s dynamic features – but the new @TypeChecked annotation allows you to selectively enable or disable type checking at the class or method level. So its now possible to enable type checking by default on your code, and then turn it off where dynamic language features are being used.

Static Compilation allows you to annotate code to be compiled down to bytecode, thereby removing Groovy’s runtime overheads and improving performance. Just like type checking you use an annotation, @CompileStatic, and can use it for individual methods or whole classes. Clearly this is more likely to be used selectively where performance is more important than being able to use the dynamic features of Groovy – which are lost inside the code marked @StaticCompile.

You can find out more about the new features of Groovy 2 from Guillaume Laforge’s article at infoq.

Second up was Stéphane Maldini discussing a new event bus plugin he’s beed working on. This was my main reason for attending this particular user group meeting as it promised easy integration between Grails applications as well as providing functionality that flows all the way through into the browser. We weren’t disappointed.

After spending some time explaining the messaging models supported – point to point, publish/subscribe as well as content-based routing (allowing you to target recipients based on content) Stéphane provided some code samples before giving a demonstration showing an interaction in one browser window showing up seamlessly in two other browsers. It was all very impressive and the Javascript interface in particular looked nice and clean. THe Javascript component utilises web sockets by default but gracefully falls back to Comet if the browser does not support them.

At the moment event bus is still a milestone release (1.0.0M1) with Milestone 2 due in the week ending July 20th and Milestone 3 shortly after. Stéphane is aiming to release version 1.0.0. alongside Grails 2.2 – which also happens to be the first version of Grails to adopt Groovy 2.0.

Event bus is open source and available on github, as is the Grails client-side plugin. Sample code is also available.

Skills Matter provide a video podcast of the evening.

Continue reading »]]> About ten days ago I finally received the OTA update for my Galaxy Nexus that would take it from 4.0.2 to 4.0.4. Of course it didn’t show up at a convenient time despite my numerous checkin requests over the previous two weeks, I was on the motorway, using Google’s Navigation app. Ten minutes later however I was in a stationary traffic jam so I elected to apply the update. All went well and the navigation app was back and running inside ten minutes.

However today I realised that in the process I’d lost my root access. I’d downloaded a leaked copy of the “S Voice” application that is installed on the new S3 – apparently it works very well on the Galaxy Nexus – but found I couldn’t drop the file in the system applications folder. A few tests showed that (a) su was out of date and (b) although the binary was still in place, I wasn’t getting root access. So, here are the steps I took to regain root:

• Download the latest Clockwork Mod recovery image (visit this page)
• Download the latest copy of su from Superuser (visit this page)
• Turn off the phone, then turn in on in bootloader mode by holding down both volume buttons and then pressing the power button.
• Connect the phone to your computer with a USB cable.
• Fire up Clockworkmod Recovery:

fastboot boot recovery-clockwork-5.5.0.2-maguro.img

• Clockwork Recovery starts. Scroll down to ‘mounts and storage’ and click the power button.
• Scroll down to the line ‘mount system’ (if it isn’t at the top of the list) and click the power button. /system is now mounted as a read/write volume.
• Upload the new copy of su I downloaded earlier using the following shell command:

adb push su /system/bin

• Set the file permissions using the following shell command:

adb shell chmod 06755 /system/bin/su

• Reboot the phone:

adb reboot

Hey Presto! Root access returned.

In the next day or two I’ll post some notes on how I installed S Voice. For those who are interested, you can find a link to the S Voice application posted at xda developers. You’ll need root first.

Continue reading »]]> Last year’s Google I/O conference sold out in under 60 minutes. This year, with many more tickets available, it sold out in just 28 minutes (according to my browser) or 20 (if you read Vic Gundotra’s Google+ post here). Google could have sold every ticket at least three times over last year. Or, if you just count the tickets not sold to previous attendees – at least ten times over.

In any event many people were not going to get a ticket for this year. I was fortunate enough to go last year (thanks to eBay) and after reading this year’s registration FAQ was hopeful that demand from scalpers would be damped down by the price rise and non-transferability of tickets making re-selling a big gamble. Add in the fact that this year there was no opportunity for previous attendees to pre-register and you have 5000 tickets available instead of the 1500 or so. What’s to go wrong?

Well first there was a hint of a ‘coding competition’. This didn’t come to fruition, all you needed was to be able to code your way through creating a Google+ account and a Google Wallet account, and then sit pressing F5 (or Command-R) until registration opened.

Next there was the concept of ‘first come, first served’. This is a silly statement to make as we’ve already established that demand far outstrips supply. Registration opens and immediately there were, apparently, over 6000 registration attempts. Per second. So first come, first served has no meaning in this context. All it does is allow Google to say that they had no favourites. However I’m already reading posts that say the ‘searching for tickets’ page simply polled the server periodically. This could still be a first come first served system, but from the outside it doesn’t look that way.

The fact that my browser didn’t start reporting the conference as sold out for 28 minutes indicates what? Simply that the system in place was, just like last year, woefully under-sized for its task – it just didn’t crash horribly like last year.

So is that the end to the PR own goal that Google I/O registration has turned in to? No. The first eBay listing was up just 39 minutes after registration opened with a general admission ticket up for sale at the bargain price of $2000 and as I write now there are two sold tickets and one cancelled sale.

I’m sure Google won’t be reading this blog post any time soon but I have some simple and easy to implement suggestions that, while they won’t cure the demand for Google I/O, can be used to minimise the bad press.

1. Ask people to pre-register. Have a pre-registration window and once the closing date has gone, that’s it. Only those that have pre-registered can then apply for a ticket. You now know the level of interest and can think about how you are going to make tickets available. Or taking up an option on more space.

2. No transfers allowed. Period. If you can’t transfer your ticket, you can’t sell it. Allow people to return their ticket for a full refund (feel free to sting them for a small admin charge if you like).

3. Run a ballot for returned tickets. This is where pre-registration comes in again. When a ticket is returned, draw a name from those remaining. Give them the ticket.

4. Stop giving stuff away. Even if you stop the scalpers you won’t stop people registering who have no interest in developing on the back of your products, because of the free stuff you hand out. Make it clear at registration: no freebies to be had at this conference. Instead, allow all registered attendees and speakers to purchase one item that will be useful in their job at a reduced cost.

Having been to Google I/O once I found it to be a fantastic experience and one I will never forget. After this year, though, I also expect never to go to again, because the odds of getting a ticket are use too long. At least the £2500 saved by not going (plus another week’s fees from my current client) allows me to look at purchasing more development hardware and take a few days off working on somebody else’s software to work on my own.

I’m not asking Google to change their core ticket sales process. With demand far exceeding supply, every system is as bad as the next and all Google can do is to reduce demand or increase supply. I won’t be watching live streamed presentations – I can watch them at my leisure on YouTube – but I am thinking about organising an Android hackathon with a group of friends.

Continue reading »]]> Samsung is a company that has successfully renewed itself in recent years. If I want a good quality and feature packed TV I look at Samsung, not Sony. And If I want a good looking, up-to-date Android device then they have some fantastic hardware that performs well and looks good.

At Google I/O I got my hands on the Galaxy Tab, which is about to receive an Ice Cream Sandwich upgrade. This was when I first started to realise that Samsung have become, compared to the rest of the large tech companies, more Apple-like. They have a distinct brand name for their devices – Galaxy – and their hardware feels good and looks good. I’ve had my Tab for nearly a year now and when I’m not developing software it tends to be my go-to device for email, web browsing and media consumption.

Unfortunately Samsung dropped the ball a bit on the Galaxy Tab. It’s never good to hand out a new device to 5,000 tech-heads because if there is a flaw – they will find it. The Galaxy Tab’s main flaw was its inability to transfer files over the USB cable using the company’s Kies software – or indeed any other software. The other major irritation was that you could only use their own mains charger to recharge it. Finally there was the ‘not Apple’ dock connection which has the same dimensions as the iPod/iPhone dock (but with different keying). So you needed to carry around an extra charger and an extra cable.

At the start of December last year I finally upgraded my two year old Nexus One, buying the Samsung Galaxy Nexus as a replacement. The longer I have this phone, the more I like it. Yes it is a little on the large side for some, but the user experience is fantastic and the phone feels solid and very well put together.

However Samsung have yet again dropped the ball, hampering it with the same MTP transfer protocol that the Galaxy Tab has got, only making a 16Gb model available in Europe, and refusing to give it a microSD card slot. Amusingly this confuses some web sites that will push large microSD cards as ‘extras also purchased’ alongside the Galaxy Nexus (I’m looking at You, Amazon).

However the worst part for me is that Samsung failed to release any accessories for the phone when they made the phone available. No cases. No USB adaptors. No batteries. No car cradle.

The cradle particularly annoys me. Now first I should explain that there is a cradle available, but only in the USA and for the Verizon version of the phone which is a slightly different shape. It won’t take the GSM version of the phone, so Samsung are losing sales of their cradle across all of Europe and beyond. I’ve been using my phone as my satnav since the day Google released Navigation and it works really well. But at the moment I’m driving up to 400 miles a week and I can’t put my satnav in my line of sight when I’m driving. That’s right. Here we are near the end of March (16 weeks after launch), with a phone that was released in mid-November, and still no car cradle. I ordered it from Amazon in mid-December when the shipping date was January 2nd. The shipping date for my order is currently shown as Feb 17th – April 13th. The battery I ordered at the same time showed up in the middle of February, just two months after it was ordered.

Samsung probably won’t be able to attain the kudos that still comes with an Apple product (even as Apple starts to show signs of losing their famous attention to the whole experience) but they could, with application, gain a strong reputation for their products. But only if they release their products when everything is ready. And the cloud services they are rumoured to be building? Please, Samsung. You really aren’t Apple. If you want loyal customers then release good hardware with high quality software – and accessories available from day one. And keep upgrading the software on your phones. Don’t expect any loyalty if you leave us out in the cold on accessories or software updates.

Continue reading »]]> Android has been taking a back seat recently (although that is about to change) as the new Formula One season looms and I’ve been comprehensively overhauling the fantasy game web site I’ve been running for over ten years, fantasy-f1.net.

Last year I spent three months removing the Struts MVC layer, restructuring the underlying code and then implementing a new JSF 1.2 user interface. Once you’ve got used to the quirks of the JSF lifecycle its a relatively frictionless way to create well-structured and component-based web sites. There’s no need to write tag libraries any more – just develop your component in situ and then extract it into its own XHTML fragment and – hey presto – you have a re-usable component.

Last year’s effort was very plain, being a bare minimum effort to produce a working web site. This year I threw away all the HTML from last year and wrote a completely fresh user interface. The experience was very rewarding – the site was developed rapidly and with little pain – and backed up my opinion of JSF as a rapid way of creating or re-skinning web sites.

Working for the last nine months on a high-profile broadcast media web site has also had the beneficial effect of reinforcing and extending my CSS skills, making the process of creating a consistent layout and colour scheme much quicker. Having used a few RichFaces components last year I’m now also writing my own rich client-side functionality using JQuery – RichFaces is not a good fit for this kind of site.

So with a newly skinned web site I’m hoping it will have its best year yet in terms of the number of people who use it and how much they use it. Last year the site had 2.9 million page hits over the F1 season, this year I’m hoping to hit 5 million page hits and to pick up an extra 2000-3000 users.

Having nearly (but not quite) reached the end of this work the next step is to set up my new hosting environment and put out the next release of Audio Clock, before starting work on the next Android application on my list. Watch this space…

Continue reading »]]> At this year’s Devoxx, Google’s Tim Bray gave a thought-provoking keynote which covered several areas but what stood out for me were his comments around writing applications for Android. In summary his message was “give software away and sell a service” and “make it social”.

Giving software away and selling a service is a whole other discussion which I intend to address separately. With regards to making it social, this is fine provided that there is a significant social angle to your application.

Anything we do that involves a social element – playing sport, going out to the theatre or cinema, even attending an evening class – these are all areas where applications can justifiably build in a social element beyond the now-standard “share via” context menu. A fantasy football application that makes it easy to share your team with friends, or a study helper application that lets you interact directly with others on your course through existing social networks. Invariably this means giving the application access to your address book, which is fine provided that the benefit to doing so outweighs whatever risks you perceive.

I am very cautious when installing and updating software: what privileges are required by the application, how sensitive are they, are they central to the application’s purpose? Some cases in point:

Google Docs requires read access to my contacts. Now my sporadic use of Docs doesn’t really benefit from integration with my contacts list, but as the app publisher is Google, I don’t worry unduly about it. Likewise the PayPal application. As a payment processor, PayPal must maintain a high degree of trust with its users, so the fact that it requires access to my contacts does not worry me from a data security angle. LauncherPro is a whole new launcher application which by definition requires access to almost everything you can think of. But as a widely installed application it has built up a level of trust with its users, and this in turn allows me to trust it.

Moving on I have a couple of apps where I have decided that the benefits of the apps outweigh the fact that they require access to my contacts - Any.DO and Catch - both note taking and (potentially) collaboration tools. I use them almost exclusively as personal to-do lists and so far they have done nothing to violate the trust I have placed in them.

Exhibit ‘A’ is RingDroid. Having used RingDroid on my Nexus One I attempted to install it onto my Galaxy Nexus. It wasn’t available (as open source I expect an update will appear eventually), but Ringdroid (Social Edition) is. And it requires not just read access to my contacts, but write access too. The primary purpose of Ringdroid is to let you extract part of an audio file and convert it into a ringtone for your phone. Social networking is not a core feature of this – period. Ringdroid (Social Edition) will not be making an appearance on my phone – ever.

Exhibit ‘B’ is Barcode Scanner which not only requires read and write access to my contacts, but also access to my browser history. I’m scanning a barcode and my primary purpose is to look up prices and reviews. This does not need access to my address book or browser history.

Android allows us to develop separately installable components with their own permissions, so these edge cases can still be made available – but as an option, rather than as part of the core download. I will continue to refuse to install any application requiring address book access where that access is not core to the application’s purpose.

Continue reading »]]> Having published a first Android application Audio Clock in the Android Market my attention has turned to developing something new. Audio Clock was simple but this new application is on a whole other scale.

Audio Clock had a minimal UI – in fact just some configuration views and a notification bar entry – and ran in the background, waking every 15 minutes to chime. It has no web component, no remote connections. In other words it was kept almost as simple as it was possible to be whilst till providing some useful purpose.

The current application, which I should be able to start testing in the wild with some willing victims within a week is completely different. It will have a relatively complex UI. It will use more hardware features. It will require an internet connection and I will have to write a server component.

Having spent the last four months working on Groovy and Grails applications it was only natural that I should write the server using the same technology. After all, Groovy and Grails now is everything Java and the JEE web tier should have been a couple of years ago.

Where to host it though? I’d been considering Google App Engine – it has good Android integration including push notifications, but my attempts to get something going were patchy and then Google’s new price list came through. I considered self-hosting to start with, but my Virgin ADSL connection is fast when it works, but is too intermittent to be trusted.

Around that time a colleague at work introduced me to Heroku.com, a cloud application platform that started out supporting Ruby but has recently started supporting JVM based languages as well. Some further leg work then led me to this post from Tomás Lin which took me from zero to a deployed Grails application in under 30 minutes using Maven and Git. Fantastic!

So now I’m powering ahead with an embryonic server that can talk to my fast-developing Android application. With luck and a following wind I’ll have end-to-end communications implemented in a couple more evenings work.

By the way – Audio Clock is ticking along nicely (if you’ll excuse the pun) at one sale a day. No marketing, no seed purchases or reviews. Just consistent sales and a list of enhancements I’ll be adding over time.