Blog

At the 89th SPIN meeting recently, Ewald Horn of Wysetalk talked about Android Live Wallpaper development. The first part of the talk was around the hows and whys, and the second part was a code demonstration. The slides and the code are available on the SPIN event page. Below are my brief notes from his talk.

Live wallpapers are good for Android version 2.1 and up. They are very popular, and they are fun and easy to develop since Android can handle a lot of the hard work for you. They can be used as brand awareness and marketing tools They’re better with the sound off, though, and can be big battery drainers. Live wallpapers offer a good starting path into Android game development. The most popular wallpapers are very similar to games (that mostly play themselves).

Since live wallpapers are a service, there are a number of things that we know. Wallpapers:

• run all the time;
• have access to system resources;
• have access to the Android platform;
• don’t require the NDK, so you don’t need to go native;
• need to handle a lot of events.

Vogella – Live Wallpaper tutorial is a good starting point, but watch out for some typos and bugs.

It’s easy to get started because all you really need are some config files and settings in a manfiest file. The only permission required is android.permission.BIND_WALLPAPER. The building blocks you need are the Live Wallpaper service (which you Extend) and the settings Activity. Use the boilerplates that are provided to make it easier for yourself. The WallpaperService Engine handles rendering, lifecycle and interactions. Rendering uses Canvas. It’s possible to use OpenGL if you want or need to, but it’s much trickier. The API is very helpful, especially for hi-dpi concerns. For the lifecycle it’s important to track visibility and changes. You should be asking: can I draw, should I draw? Think about possible interactions: touch and gestures.

I’m running around at the moment organising a RailsBridge event in Cape Town, following on from the workshops that ran around RubyFuza earlier in the year. I’m very excited to announce that we’ve just pushed the (work in progress!) site live to RailsBridgeCapeTown.org. Our first workshop will take place in July. With luck, we’ll be able to turn it into a regular event: a workshop every three months.

RailsBridge’s tagline is “Free Ruby on Rails workshops for women and their friends.” It runs over a Friday night and Saturday day, and provides an introduction to Ruby and Rails. There’s more detail on the RBCPT site. RailsBridge caught my attention because it’s about things that I’m interested in and care about: gender politics in the tech space, and learning and education. I’d like to say a big thank you to the teachers and organisers who are volunteering their time to help make this happen.

If you’re interested in attending please sign up on our mailing list for announcements. If you’re interested in helping out, I’d love to hear from you: you can get in touch with me via mail or on Twitter @maxbarners.

On April 25th, Gavin van Lelyveld and Greg Benner gave talks about communication and optimisation for the 3rd Cape Town Front-End Developers meetup. Gavin’s slides are up on Speakerdeck, and Greg’s are up on Slideshare. Below are my brief notes from their presentations. Both talks were interesting, and it was great to have talks about two very different areas of how we work. Our next meetup is Rian van der Merwe of Flow talking about Responsive Web Design in Africa.

“But that’s not what you asked for!” by Gavin van Lelyveld

Gavin’s talk was about the communication between developers and users: where some problems are, and how we can improve things. He encouraged us to think of users not just as the people using the sites that we create, but also our team, our bosses, and ourselves. He suggested we ask questions, without judgement, because any problems they have become our problems.

Gavin talked about openness and humility, and about making the customer part of the team. He discussed being present, mindful, and talking the time to observe and discuss problems. He recommends favouring high bandwidth communication, with face to face being the best.

He summarised by recommending that we: listen more than we talk, be compassionate, and pay attention.

Web Optimisation by Gregory Benner

Greg’s talk was a whirlwind tour of optimisation: the whys and hows. He singled out images as the biggest target for optimisation.

He talked about why optimisation is important: statistics show that if your site isn’t fast, people will leave it. Optimisation will also offer SEO benefits, and will save you time and money. The biggest concern, especially for mobile, is latency. Greg covered a number of tools that can be used: Google PageSpeed, Yahoo YSlow, Pingdom’s Web Site Speed Test, and the Web Inspector in the Chrome browser. He covered css sprites, using data URLs for images, and tools such as smush.it for compressing images.

He recommend becoming familiar with command line tools, such as grunt. He said that although they can be scary at first, they offer a lot of power. Greg said he’s a fan of the Yeoman set of tools and frameworks. He also recommends CodeKit (Mac only).

In November of last year, I took a job at Unboxed Consulting. It’s been quite a change, and six months seems like a good period of time to review what I’ve done and learned since then.

Technical

Having previously worked only with PHP, and almost exclusively with WordPress Themes and Plugins, moving to Ruby on Rails was a big challenge. Ruby is a delight to work with. Although I’m a Front End developer, I’ve picked up enough to be able to read and understand it, and to write bits of my own when necessary. Rails is an amazing framework, and feels very intuitive. A guess about how to do something, or where to find it, is often correct.

Working on bigger projects has meant I’ve been able to flexing my HTML, CSS, and JS muscles in different directions. I’ve also been using new tools like Jasmine, which leads me nicely onto the next section.

Process

I’ve really enjoyed my introduction to Test Driven Development (TDD). Although it was a bit of a mind bend at first (and, truth be told, sometimes still is), I’m completely sold on it as a way of making software. I’ve been using Jasmine for testing Javascript and RSpec with Capybara for the rest. Combining TDD with Pair Programming, specifically ping pong style, makes me very happy. It’s a fun and challenging way of writing code.

As you might have guessed (or known), Unboxed is an Agile shop. Although it felt like a good fit, it took me a while to feel comfortable with how things work. It’s nearly ten years ago that I worked as part of a team on a daily basis, and that was in a large financial institution, doing spreadsheet-related things. The processes there were quite rigid and controlled, and not very exciting. I much prefer the Agile way!

Company

Working for a company has also afforded me other opportunities that would have more difficult, or not possible, otherwise.

• I’m a bit of a link hoarder, so I’ve contributed a lot of links to the uxbd weekly developer newsletter.
• I’ve got a regular location for Open Device Lab sessions at the Unboxed offices.
• Inspired by a talk at http://rubyfuza.org/, I helped set up a hubot for our Campfire chatroom.
• Unboxed has sponsored sessions of the Cape Town Front End Developers Meetup and SPIN.
• I’ve asked smart friends to help us do more interesting side projects.
• Most recently, still in progress, I’ve got help from the fellow unboxers to run a RailsBridge workshop in Cape Town in July.
• And, perhaps most importantly, I took my Nintendo Wii to the office.