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:
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.
Been using Heroku for a new project and these are the commands which I must learn and remember. Until then, I’m jotting them down here as I go along:
heroku ps <- Heroku Process State. Lists the currently running processes
heroku ps:scale web=1 <- Scale processes. heroku ps:scale <Process Name>=<No of Instances>
heroku logs
heroku open
Edit your ~/.profile file
Then add something along the lines of:
if [ -d "/home/matt/Development-Tools/android-sdks/tools" ] ; then
PATH=”/home/matt/Development-Tools/android-sdks/tools:$PATH”
fi
if [ -d "/home/matt/Development-Tools/android-sdks/platform-tools" ] ; then
PATH=”/home/matt/Development-Tools/android-sdks/platform-tools:$PATH”
fi
I tried ‘~/Development-Tools…..’ but had no luck.
Anyway, restart your machine and jobs a good’un
Another post on Little Printer? Yeah, you guessed it 
I’m not going to say much on it apart from a congrats to Berg for releasing it, it’s a fantastic looking product and I’m looking forward to getting my hands on one and secondly the reason I like this is because it’s moving away from digital.
It’s a bit of a weird thing to suggest (especially for an app developer), but a small chunk of paper I can grab in the morning, with all the bits of info I need for the day, that’s pretty handy. The main reason I think it’s going to be successful is because the output is something physical.
It’s easy to believe that everything should be in the cloud and to be honest I keep the majority of my content in cloud. At the end of the day I don’t want to worry about back-ups and how to access content when I’m away from my usual computer. However, with this mentality comes a sense of letting go of all things physical, paper notes, CD’s, DVD’s, even hard drives, but should that be the case?
The root cause of my interest stems from the loss of physical attributes which occur when shifting to the cloud. This was peaked during a completely different discussion about applications like bump with one of my close friends Andy Coghill, who has a background in product design.
After starting a conversation around substituting a physical business card for a digital one, the first thing Andy focused on was the loss of touch.
Taken back I probed further questioning why he didn’t like the idea of things like NFC, QR codes or bump, thinking NFC was the most natural way to do it and Andy simply moved onto to push that touching, feeling and owning that card was far more powerful. I had to agree. My software engineer background went to the toolbox and found the usual tools of the trade, cloud computer, NFC & mobile devices. His product design background went to the toolbox and found the materials, the user perception and everything he knows and loves.
Now consider Little Printer, you can see how that might apply. Having a physical receipt sized piece of paper with the vital bits of info you need for the day has a number of physical properties that you could easily overlook. All this printer offers is a link between the cloud to the physical, something which has been overlooked all too much these days.
If you want to find more info then check out: http://bergcloud.com/
I’ve been working with team Phaedrus at Future Platforms HQ to develop the Qt version of LastMinute.com’s hotel booking application.
Being one of the first Qt projects I’d worked on, I was amazed at how easy it was to get to grips with Qt Quick, Nokia’s technique for developing applications in QML and Javascript.
After the application was finished Nokia asked if we would be happy to talk about our experience developing with Qt and you can see the result below.
If you wanted to hear other developers experience with Qt then look no further than http://www.developer.nokia.com/Develop/Qt/Videos/.
Oh yeah.
The site was looking a little bit outdated and it wasn’t quite fitting my needs:
If you find any problems with the site please give me a shout, otherwise go and check out gauntface.co.uk and enjoy the blog.
p.s. I’m sorry for out right blocking users of IE9 or less . . . . but unfortunately I don’t want to cater for such a small portion of my visitors by building vasts amount of backwards compatibility.
Ever wanted to view the source code for an Android method?
Boom : http://www.martynhaigh.com/blog/2011/10/20/android-sources-plugin-for-eclipse/
Cheers Martyn.
To use cmd+shift+f to format layout and xml files nicely just do the follow:
Search for “format” in Eclipse preferences – XML > Split multiple attributes each on a new line
Then Just go to: Android > Editors > Automatically format the XML edited by the visual layout editor
Then for formatting Java code:
Search for “line” then go to Java > Code Style > Formatter > Edit the active profile, change the Maximum Line Width to something huge like 1000
It’s that time of year when all the conferences are a go and if you’re an Android developer the key event you should have in your diary is Droidcon UK 2011.
I attended the second day of the event last year (Was in project deadline mode for the first day unfortunately) and thoroughly enjoyed it. Judging by the speaker list so far it should be an unmissable event.
The main talks I’d personally have on the top of my list: Richard Hyndman & Nick Butcher from Google, Mark Murphy form CommonsWare, Yosi Taguri from BlueVia (interesting revenue share opportunities with telefonica) and Kieran Gutteridge.
If you’ve not been to this or any of the Londroid events, this is a great event to get to know some of the people in the Android community and I’m quite excited to see how much larger the community has grown.
There are still some early bird tickets to go, so get ‘em while you can: http://uk.droidcon.com/content/register
Hopefully see you there 