Just got caught out by this little mistake for a few minutes. If you call the DbxAccountManager startLink method in your onCreate, onStart or onResume methods for your Activity then the your app will crash after you’ve authenticated. Solution: Don’t try and link before the activity is fully running. See the Activity API reference for details about the activity lifecycle.
Update: Turns out this has nothing to do with when you start the authentication. After an email exchange with a developer at Dropbox (they contacted me!) we deduced that this was due to a low memory situation, and it just happened by chance that waiting until the activity had fully started fixed the issue. Apparently a fix will be coming for this in a future update…
Here’s the error from the logcat:
I’ve had my Xperia U for about 5 months now. It’s an interesting phone, it’s a nice shape but Sony have done bad things to Android and it frequently plays a fun game where it goes so slow that it doesn’t wake up in time for me to answer a phone call before it goes to voicemail… Anyway, one of its less desirable features is the silly light bar gimmick across the bottom of the device, all it does it use up battery and make the phone painful to use in the dark.
But! Today, I stumbled upon a way to (mostly) disable it (apart from in the gallery/album app). Install the following app from the Google Play Store:
Google Play Store: Illumination Control
And then in the app’s settings, go to “Set Theme Color” and then slide all the sliders all the way to the left, you might have to wiggle them a bit first if they are already in that position.
It’s that easy! Now you can use your phone in the dark without being blinded!
For a more up-to-date look at Android design, see this updated talk.
A short talk discussing some do’s and don’ts with Android design, whilst also looking at some iOS / iPhone patterns that should not be used on Android and why.
Filmed at the Ribot studios 14th September 2011 as part of Open Studios, a Brighton Digital Festival event.
Apologies for the terrible sound quality, a camera at the back of the room was never going to work well…
A short promotional video for the Android based phone: Threedom.
Made using a beautiful Canon 7D, by Ben Breckler and myself!
This post is aimed at the sort of people within mobile app teams that aren’t technical, both designers and the (boring) business type :p
If you’re after something more technical then check out Google, the Android documentation or Matt Oakes’ crazy slides from Android Manchester‘s April 2011 Meetup.
Looking up ‘intent’ in the dictionary points you to this incredibly descriptive definition:
“intention or purpose”
That’s not hugely helpful, but it leads us to this definition of ‘intention’:
“a thing intended; an aim or plan”
So how does this translate to defining a definition for the context of Android? Essentially, an Intent is the way your app can say to underlying Android system “I want (or intend…) to carry out a specific task”.
Intents are used all over the place in Android in one way that won’t mean anything to someone that isn’t an Android developer, they allow your app to explicitly move between different Activities and start Services. If you have no idea what that means then fear not, you weren’t meant to.
But more importantly for you they are also used to allow different apps to share their features with each other. What this means is that you can have (for example) your own video blogging app and you don’t have to write your own video recorder, you can simply say to the system “I want to record a video” and the phone will either use the built in video recording app, or another video recording app that the user has downloaded. Once the video has been recorded it is then passed back to the original app. This makes a great user experience because far as the user is concerned they never left your app.
Another example could be that you have a piece of content in your app and you would like your user to able to share it in some way. You can just say to the system that you wish to share something and the user will be presented with a list of different options for sharing, e.g. sms, twitter, facebook, etc.
If there is just one thing that can handle your intent then that thing will just be used by default, but if there are several different apps that can handle your intent then the user is given a list of things to choose from, and also has the option of setting it as the default action.
This question is kind of hard to answer without actually knowing exactly what your app does. But what you shouldn’t do is rely on 3rd party apps for your app to function. Say for example that you are a large supermarket and you are building your own Android shopping experience, don’t rely on the user having a barcode scanner installed for the app to function. If you have the time and the budget to build your own scanner as part of your app then definitely do it, but don’t force your users to use it, make your barcode scanner respond to barcode scanning intents exactly the same way all the other barcode scanners do. Some users may prefer to use their own barcode scanning app that plays “Lost In The Supermarket” by The Clash in the background. Or something.
However you shouldn’t reinvent the wheel unless you need to. If the device has a camera, then it will have built in intents for taking photos and recording videos, you don’t need to make your own camera. This also helps the user as it means they get a consistent camera experience no whether they are taking a photo of their brother passed out on the floor to post on their father’s Facebook wall or taking an arty photo of Brighton West Pier at sunset to post on their flickr account.
Most Android devices also include maps. So say you want to give the user directions to your nearest store, don’t reinvent this in your app. Push them out to the built in google maps app, or any other app that they might have installed that can handle giving directions!
A classic example would be to offer to handle web addresses. So say you are a large retailer, and someone clicks on a link that directs them to a product page on your website, your app can offer to handle that request so rather than displaying the webpage it could display the product in your app.
You could also define your own specific actions. Again, say you are a large retailer, you can create specific intents that might let other apps add products directly to your basket. For example, a price comparison app could list several different retailers to buy a certain item, and in their app they could place a button that could allow the user to buy the item using your app. If you do go down this route, make sure these things are well documented!
Intents don’t just have to be used to do something in the foreground, they could trigger something to happen in the background. A great example of this is the last.fm app. The last.fm app can respond to specific intents that tell it that an app would like to scrobble a song! The last.fm app then handles the scrobbling directly without the user having to sign into last.fm in another app.
Intents are very powerful and if used wisely they can let you tie several different apps together into one lovely experience!