I’ve been a bit quiet on all the social networks lately and I am very happy to come back with some fantastic news.
I’m joining Google
As of June I will be joining the Google TV team as a Developer Advocate for Europe. What this means is I’ll be helping developers create fantastic applications for Google TV and after the GTV Hackathon held in London, I know you guys are going to keep me on my toes
This obviously means I will leaving the incredible team at Future Platforms to whom I owe a massive thank you. FP is crammed of talented product owners, scrum masters, designers, QA and developers and I feel privileged to have worked with them. I’ve learnt an insane amount from everyone over the past year. Obviously a tip of the cap to James Hugman is needed (my partner in crime in Team Phaedrus) for the continuous words of wisdom throughout my time at FP.
For now, I’ll be looking forward to my first day, but will hopefully be attending Google IO this year, so please do stop me and say hi if you spot me wandering around and fancy a chat.
Last Friday I was invited by Adam Martin to give a presentation on the current state of affairs in the mobile space. Despite the tube problems (damn you circle line) I got there on time. As usual it was a great crowd and I hope they enjoyed.
There may be a video at a later stage but not sure Adam’s plans with that. Here’s the slides and of course you are free to download them.
It’s been a few years since I finished my Masters in Computer Science at the University of Bristol. My final project was “Mobile Eye”, a thesis project exploring mobile projection techniques and interactions.
There were two things I discovered when beginning the project, mobile projection is fairly new, very niche and the majority of work undertaken was using old platforms / hardware because of output flexibility rather than platform capabilities.
My interest in this area was sparked by the Sixth Sense concept video:
Last thursday I gave a talk on the approach I take to target the various Android screen sizes. I was bit unsure how to get the information across since it was predominantly an iOS crowd (the group was originally an iOS group before changing to be mobile).
All in all I think it went well and people found it useful. I’ve put the slides up on slideshare.
I’ve just been asked for a helping hand about how to have a ListView with rounded corners, so here’s the solution.
In Android it’s fairly trivial to have a ListView with rounded corners on the first and last element. The problems comes when you want to be able to highlight the view, whether that be via press or with a focus.
The solution is nice and simple, the highlight applied by the system can be remove by setting the ListSelector color to transparent (i.e. android:listSelector=”#00000000″), then doing the same with the background, if you want to see what’s behind the ListView, (i.e. android:background=”#00000000″) and finally you’ll need to remove the footer divider (android:footerDividersEnabled=”false”).
Then in you’re background drawable of the list item, ensure it has states to cope with being pressed and focused (same as you would do with a Button).
I’ve been working with NodeJS for the past couple of months and I have to say . . . . it is incredible.
I’ve been using it for building a restful JSON API and been amazed out how simple it was to pick and getting running with. Reasons for my loving it:
God damn that NPM is awesome. Having a set up for installing and maintain plugin’s is fantastic, speeds up development and gives the platform a sense of maturity. My tip would be to use the NPM with a dependency list (package.json) It’ll help if there is a team of dev’s working on the project and will remind you of what is needed. Plus, a quick “npm install” will grab all the plugin’s needed and you can even enter in min and max version numbers of each one.
The NodeJS framework is amazingly simple yet effective to organise your javascript files in a sane way (something I’ve always struggled with in the past)
It’s javascript. I’m slowly growing a love for javascript. I’ve often found it easy to do things wrong and only ever found it possible to use for small chunks of functionality, rather than treat it as a full programming language. However having the NodeJS framework has swiftly altered my train of thought with this.
The number of people using it is growing . . . . fast.
Powerful and easy endpoint management. It is so easy to have something along the lines of ‘/MyAwesomeEndPoint/:user;/:action;/:object;/’ and catch that with ‘/MyAwesomeEndPoint/sudo/make/sandwich’ => request.params.[user, action, object]
The one thing I would love to see happen as a result of NodeJS, is an IDE or plugin for an existing IDE, which integrates JSLint and auto-complete into the development cycle out of the box. JSLint is a great safety net to catch some of those pesky things you can trip up from time to time is js, especially if you’re fairly new to javascript.
Memory management. It’s not a sexy topic, I know, but I’ve never looked into how javascript manages memory, I have only understood that is has garbage collection. This is probably one of the few instances where I’ve seen hefty pieces of javascript code running and because of the simple ‘require’ method, it’s easy to pull a chain of modules and I’d be interested to learn the memory allocation of that as a result. I think that this comes down, A.) Not investing the time to learn these things B.) Not having played with it enough to find out where I’ve abused a part of NodeJS, which will later improve my knowledge of it’s internal working.
Docs . . . . . the weird weird docs. I think this is an issue which comes from my background of Mobile platforms having a fairly hefty supply of documentation where as NodeJS, I get the impression it’s so new and moving so fast that docs aren’t really going to be maintained or have the best amount of time invested into making them more accessible. Fortunately there are plenty of articles on the web, but still.
Finally, you can get default installs of NodeJS on hosted systems, similar to just grabbing a LAMP stack from a web host. My suggestion is Heroku, you can sign up, for free, without entering a credit card and while the tools are bare bones does everything you need to get going. The developer docs are simple and targeted at getting you from joining to development as fast as possible. But I get the impression NodeJS is happy in the cloud (which is good) but not so hot if you want it for a personal site or blog on a cheap, fixed priced host. One day though….
The future for me is getting NodeJS working as a full blown web server for displaying HTML content as well as JSON data etc. coming from a single endpoint working with a nice development environment for HTML templating.
One of the weirdest things I found when working for various companies whether that’s as a developer within a company, or simply a developer using desk space in a client office, it’s always fascinating discussing and seeing how other development houses are run.
They’ll tend to mention agile development methodologies and for the most part companies will say something along the lines of “Yes we are an agile development house”. But are they? Wheres the line between non-agile and agile? Would a company actually admit to being something other than agile?
I guess the biggest issue for me is since working in companies where elements of agile were introduced and simply didn’t work to working in Future Platforms alongside the spectacular Scrum Master Cori Samuels, it kind of becomes clear where the others may have been going wrong.
Scrum for me makes a great deal of sense in development, especially when working on mobile apps which can be relatively small time to turn around. The reason I think it works so well is that by sticking to a great deal of agile methodologies and iteratively tweaking them to work with a team is kind of the key.
The obvious thing to get misunderstood is the purpose of stand-ups, it’s a catch up. It’s easy for dev’s to get wired in and not talking, so catch up and stating plans for the day ahead is a no brainer. If this turns into a hour sat down meeting (and yes I have friends where this is the case) then something has been lost in translation.
Retro’s are a fantastic way of giving kudos, stating things you enjoyed, things you didn’t and problems you have. As a developer I would love to continue working in companies which do this on a team basis. But at the same it does open things up to saying what you disagree about within a company, while this is constructive criticism, it is criticism none the less and you have to give credit to anyone who can take it on board and work with it to improve everyone’s work life.
At the end of the day I think it’s easy to overlook process if it’s just about ticking over, but if thats the case Scrum Masters like Cori are the exact kind of people you want to work at perfecting a teams process.
I’ve been messing around with Android Fragments for the past couple of days and just wanted to bung up some early screenshots and get some feedback. The screenshots shown are from a G1 running 1.6 and a Samsung Tab 10.1 (confusingly framed in a Motorola Xoom).
Seeing the changes of a platform which has grown to handle various screen sizes, various OEM alterations, various API tweaks, re-writes and now devices types has been an exciting, albeit challenging experience.
I’ve had the fortune of working with some of the best Android developers out there, but keeping on top of all of this is a must and unfortunately only experience can account for a lot of quirks in Android.
There’s been a number of times where I’ll moan about the method of achieving a task in android despite there being seemingly no reason to alter the initial attempt. Examples of this include:
‘this’ vs getApplicationContext(). A large number of examples when Android first came up passed ‘this’ around when a context was needed. This was later addressed by Romain Guy as being an easy way to cause memory leaks. But the problem is it’s easy to miss these posts and the only time you’ll need to read it is when the application starts to act in weird ways, not really giving an indication that this is the cause.
ViewFlipper. There was a very subtle bug in ViewFlipper where it causes a force close after a few orientation changes / moving between activities. The fix was simple, but it was an easy one to miss and release into wild.
Helper classes like AsyncTask & ListViewActivity. I will openly admit that this one is largely personal preference but I will still chuckle if anyone discusses the issue with me and later finds it would of been easier if they had taken the initial hit of more work. Starting with the ListViewActivity, I see little point is using this, the code saved in finding the ListView from the layout seems so trivial it is easily out weighed by the fact you can no longer extend a different class. As for AsyncTasks, the code has a great deal of boiler plate and doesn’t really simplify things (From my point of view). But the real issue is you lose freedom to spin off other threads if you need to. Al Sutton did a great talk at Droidcon 2011 on Android multi-threading.
Tiling Bitmaps. I’ve found numerous posts where people have had issues with tiling bitmaps. Again this is one of those bugs where even though the majority of the time it works, the odd once or twice it files and you end up with a stretched image. The solution, again simple, request the tiling in code instead of XML.
Back to my point, a lot of things I do in Android is a result of experience and learning off of others.
I regularly try out new things in Android and try to forget some of these issues in the hope that they are resolved. This is only ever done when I’m producing examples, where a force close caused by a bug in the Android source isn’t a real concern.
Today I’ve been working on one of the simplest app’s I’ve ever worked on. A Kitchen Sink application for Android, the main aim of which is to make themes quicker and easier as well as cover off most of the scenarios of input and state.
I’ve not done much work with Android Fragments and been using this app as a learning experience. But it has revealed an extremely old pet hate.
The Dialog.
I’ve spent a few hours hitting my head against a brick wall figuring out why displaying a DialogFragment and then rotating the device would cause a crash.
The answer was to simply not add the fragment in XML, but add it in programmatically.
These kind of issues scare me. I tend to create bespoke Dialog’s in my own app’s to keep in with a heavily customised UI, but for client code I will tend to opt for the Google code base. With bugs like these, where the outcome is determined by such a fundamental decision, it’s shows Androids infancy.
Android began to stabilise a lot before the release of Honeycomb. Now with the release of Ice Cream Sandwich I get the impression more of these bugs are going to surface. Fortunately the issues will be found faster than ever before thanks to the thriving community of developers.
