At the very end of last week I finished an update to Betan that will enable other developers to distribute their applications using the same tools I use to share private copies (usually betas) with users. My website provides details about Betan
I don’t know whether other developers will be actually motivated to use Betan, since it does involve at least one additional step over simpler mechanism such as just emailing the APK. The developer needs to encrypt the published APKs.
What motivated me to produce a more secure way of distributing beta copies of my applications was not that, if the APK was shared, some people would be able to use my application illegitimately. Instead I’m more motivated by ensuring that my users have a well tested product, however they procured the application — this is my reason for sharing beta copies in the first place.
The possibility that some poorly tested APK which erroneously wipes user data might gain broad distribution is enough of a motivation for me to write Betan. It may not be enough of a reason for other developers, in which case I may remain the only listed Pubisher.
This would be a shame, but the work to broaden access to Betan was not that great thanks to the rapidity with which I was able to put a simple web app together using GAE and GWT (about 4 hours). Most of the work consisted of tightening-up the command-line tool, tweaks to the android application (mostly listing publishers and better landscape support) and documentation.
Whether or not Betan is adopted by other developers, at least one more revision is planned — it will finish support for constraints on the phones to which applications can be installed and provide automatic notifications to users when newer versions become available.
My Android home-screens. (Click for a larger image).
Since I developed my first live wallpaper for Android I’ve been interested in how people organize their home-screens. With the measure of flexibility that Android provides for customizing the stock home application, I couldn’t imagine adopting a different type of phone unless it offered a similar degree of control; it’s an essential part of the phone’s usability.
Some comments about my layout:
I keep a consistent horizontal band clear across all screens, this is a safe zone where I can slide the screen comfortably. I can hesitate, jab, and scud and not worry about launching an application.
Each screen has a different background colour. This means that I can identify which screen is which preattentively. The backgrounds transition smoothly between the colours, so the appearance is much less jarring than the screenshots suggest.
The central screen is always available, in any situation by pressing the “Home” button twice, so the things I do most often are represented here, together with actions that I need to be able to do urgently. So at the top I have a search bar, underneath I have the people I contact most frequently (this row used to include an icon for the browser until it became integrated into the home app, hence the gap), and at the bottom applications that I usually need in a hurry. The screens either side of the central home-screen are still fast to get to and contain the bulk of my remaining shortcuts and widgets.
The left-of-center screen contains folders for the types application I use most often. They are Media (music, pictures, video and streaming radio), Comms (includes email, messaging and blogging), Games (typically puzzles) and Develop (applications that I’m developing or that assist development). The bottom of this screen used to contain bookmarks, but I found that these weren’t particularly useful.
The right-of-center screen contains applications that I find it convenient to have quick access together with power controls and my own widgets.
The leftmost screen contains pictures of my children (how could a collection of home screens be complete without that?) and the rightmost screen is kept blank so that I have a test area for the new widgets and wallpapers that I’m developing.
It reads as though I’ve given this all too much thought, but really it’s just evolved this way because I’ve continually adjusted the phone to my way of living and working. What I find most remarkable about this is that for all the years that I’ve been using computers, my desktops have never been anything more than a dumping ground (Windows) or a blank slate (Linux) that I never customize. I’m left pondering why my phone should be so different.
This weekend I finished work on the first version of Betan. It’s an application that allows me to easily distribute private copies of my Android applications to beta testers, clients and other developers.
Privately distributing Android applications to non-developers is something I’ve long found awkward and I’m really pleased to have a tool that makes it much more straightforward.
It consists of a small Java application to encrypt APK files for upload to a webserver, and a simple Android application for downloading and installing them.
I think the great thing about Betan is that it wouldn’t take much work to make it a shared tool for other Android developers; each developer would encrypt and upload their own apks; I would just need to maintain a list of publishers that I present to the user.
I’m currently gauging interest, so if any Android developers are interested in using Betan to distribute their Beta versions, just get in touch; it’s very basic at the moment, but with interest it could grow into something better.
As promised in an earlier post about intents I’m sharing a tip on how to return dynamically generated resources from a ContentProvider — though what’s written here applies equally well to an Activity returning a result.
The basic scenario is this: You have implemented a ContentProvider and you want to use it to return something that is too big to fit into a cursor, say an image. It’s clear from the relevant Android platform javadocs, though perhaps not from the general ContentProvider documentation, that this is done by implementing openFile and returning a ParcelFileDescriptor.
But now suppose that the image resource is being rendered on the fly. How do you implement openFile?
As per the contact of openFile you need to return a ParceFileDescriptor which means that the resource must be returned via an open file (or possibly a socket, which we’ll ignore). This means that the image must first be written to a file, which is then opened as a ParceFileDescriptor. The interesting question here is when do you delete the file?
You can’t wait until the calling process has finished reading the file because (a) you won’t get notified when that occurs and (b) it may never exhaust the stream anyway. You can’t rely on the calling process to delete the file for you either, also, the whole idea behind wrapping the resource in this way is to guard it from direct access by other processes. You could delete the file after a fixed time period — assuming that the caller will have finished reading the file by that time. But this is unnecessarily complex, because the answer turns out to be very simple:
You delete the file immediately after you’ve opened the ParcelFileDescriptor but before you return it from the openFile method. Here are the relevant lines of the PlantProvider class from my Daisy Garden application; the try/finally block is there to ensure the file gets deleted no matter what — the last thing we want to do is leak precious storage space.
The reason this works is down to the way that Linux filesystems operate: directories maintain links to files, when a process opens a file a new link is created, closing a file or removing it from a directory removes a link. When there are no links to a file, the file is deleted.
So by opening the file in our application, we create a link to it. Then ‘deleting’ the file actually unlinks it, but the file won’t really be deleted until the file descriptor is discarded (ie. the last link is removed). This will happen automatically at some point after the calling application has finished accessing the file and any associated ParcelFileDescriptor objects have become garbage.
So it’s a very simple solution, but only if you know something about how the filesystem can be expected to work on Android devices.
Although I’ve been building Android 2.2 (Froyo) from source, I’ve been too busy to play with it on a device. Yesterday evening, my phone got an OTA update and I’ve been using it intensively since. These are the first things I’ve noticed, and they’re all good*:
I really like the button combination at the bottom of the stock home application. Three things I commonly use my phone for: making calls, running apps and browsing, all clustered and available from every page of the home app.
The scrolling in the UI is much much smoother. It’s across every application — so either ListView got some magic dust sprinkled on it by the Froyo fairy, or the JIT is demonstrating its effectiveness; swiping the home app is much smoother too.
The Call log screen now groups sequential calls to the same phone, it prevents multiple attempts to call someone from cluttering-up the log. It’s visually a bit busier, but in practice makes the UI quicker because there’s less scrolling.
It’s going to take developments on a number of fronts to resolve all the Android Market issues. But any improvements to the UI are welcome and there are definitely some. Comments can now be rated in addition to being flagged. Comments are now on a separate tab; I like this, it’s more intuitive, faster and fairer (the last 3 comments now hold less sway). A “Did you mean” feature has been added to the market search too. Undoubtedly useful for clumsy screen typists, it doesn’t appear to be on-a-par with the same feature for web searches.
None of my applications broke (AFAICT) and all of the applications I use on a regular basis have continued to work seamlessly. This is a characteristic of the Android releases in general: as the platform has matured, fewer and fewer issues have arisen on each update (at least from my perspective as a developer).
The stock keyboard now makes entering punctuation much easier. This was always a pain-point for me. Hitting space after a word now suggests common punctuation symbols. Perhaps reflecting the times we live in, the exclamation mark gets top billing (the amphora gets a place too). I’m slightly surprised by the presence of the underscore in the absence of the hyphen.
The new debugging notification icon is far better than the warning icon it replaced which so generic it could become confusing. A small but very welcome improvement.
The power control widget includes “Auto brightness” as an option. I don’t tend to use it, but it fills a hole in the widgets usability.
There is one negative - which doesn’t really qualify as a mark against Android itself: Flash performance. I’ve maintained a disinterested perspective on the desirability of mobile devices running full-fat Flash. I can see that users want access to all the website content they are familiar with, and the value to individuals and companies who have already invested lots of development in Flash is obvious. But I’ve always been skeptical of its suitability for mobile processors. It seems this is a hurdle they have yet to overcome, combined with the repeated browser crashes the Adobe Flash plugin induced, my skepticism has only grown.
One of my favourite things about the Android platform is how easily application can share data using Intents and ContentProviders. They provide a universal basis for Android applications to interoperate and I try to expose them whenever it’s practical, even for something as singular as my Daisy Garden application.
I’ve just published a new version of Daisy Garden and with it, Intents and ContentProviders that enable the users of other Android applications to choose flowers they have grown in Daisy Garden — assuming that the developers choose to support it. And the great thing is that supporting third-party intents is very easy to do (and even if no other developers use them, they will be heavily used to integrate my own applications).
The Java code embedded below is a self-contained Activity that responds to a tap on the screen by inviting the user to pick a flower and then displaying the flower as a bitmap. There are two basic parts: forming an Intent for the user to pick a flower and forming a Uri to the flower’s bitmap. Both of these aspects can be customized; messaging to the user, and the bitmap size for example.
It’s very simple — more than half the code is boilerplate and comments. And this is what’s really good: in a well structured Android application this functionality is simple to expose too — I’d go as far as saying it’s almost automatic, so there is very little reason not to share (non-sensitive) data between applications.
Having said all this, there is an interesting technical detail here that meant that I had to give some thought to exposing the bitmaps. Daisy Garden is generating the flower bitmaps “on-the-fly” when they are requested from the ContentProvider and it’s not obvious how to share these unless you know a little about how Linux filesystems work. I’ll try to find some time to outline the technique in a subsequent post.
Java code follows:
A poor bit of user interface design in the twitter widget for android in an otherwise a well designed and intuitive application.
What do you think the “Update” button is going to do?
Yes, it’s 3.
It can’t be 1. As android developers will understand, you can’t usefully put an editable text view into a widget (the Google Search is not a bona-fide widget). So the designers/developers have followed the pattern of showing the “Create Tweet” activity when the text view is clicked. This works really nicely.
And it isn’t 2 either. Even though the twitter website, and the rest of the android application, refer to the action as “Tweet”, the “Update” button does exactly the same thing here. It duplicates the action of clicking in the textbox. This is wrong on three counts:
What prompted me to post this is actually a second (and I feel more significant) issue with the app: there is no “About” screen, no information about how to contact the developer, not even any confirmation that it was developed or licenced by twitter.
I would have emailed my observations instead of posting them, but they weren’t courteous enough to provide their contact details.
Change notification
Change dialog
Change dismissed
The Android Market has its deficiencies. I don’t think anyone would deny that. One of the niggles is that there’s no place to list the changes between application versions.
I think this is very important in Android applications because the limited screen space often necessitates moving access to core application functions into the menu. Users who are already familiar with an application may never discover a new feature that has been added to a menu that they opened once and never since.
Instead of lamenting the Android Market’s inability to display my application changes to users, I decided that the information was important enough to move in-app; in the past I’ve simply logged changes on my website. The design I settled on was to introduce a small notification at the top of my main application activity - about the size of a mobile ad - that appears if there is change information to present to the user. The user can tap the notification to read details about the changes in the latest version.
Not all updates will need explanations, so the user may not receive a notification on every update, and users can cancel a notification without bothering to read it. Accidentally dismissing the notification isn’t much of a concern since on the next update the user can page backwards and see the descriptions of previous changes.
This functionality will be included in the next release of Daisy Garden. I think it works well and I hope users like it; the use of animations to show and hide the notification adds extra bit of polish. And I’ve implemented it as a library project, so I’ll be able to introduce it into my other Android projects.
I think every developer should consider adding something similar to their applications.
When I developed Daisy Garden for Android one of my goals was to build a simple environment in which people could share something, knowing that there was no possibility of being offended, or of giving offense. I certainly wanted an application where I never needed to be policeman to its users.
Imagining the phone in the hands of, say, a five-year-old child, it turns out that it is harder than one might expect to build something that permits safe and ready sharing; there are many constraints:
No user-supplied text — As soon as you allow users to type something - anything - and exhibit it to other users, there is the obvious potential for rudeness. I’m (broadly speaking) a libertarian so this doesn’t bother me much, but its obviously very easy for daft individuals to actively offend others in this way. Limiting the amount of text is useless, the Anglo Saxons bequeathed us a wonderfully rich collections of short curse words. Even with three characters, someone is going to try and produce an ASCII art penis, I just know it, because…
No user-supplied-imagery — …any environment where the public can upload photographs or pictures (even ones made from ASCII characters) will, eventually, contain pictures/representations of genitalia. I’m not sure why this is, perhaps sociologists can already explain the phenomenon, but it’s certainly lemmatical that…
Limited composition — …whatever medium you provide for visual expression, someone will use it to draw a penis. Even Nintendo were powerless contain this urge of humanity. Did they ever anticipate that inviting users to compete using their Mii designs would provide a worldwide forum for pornographic avatars?
Now, collaborative filtering can certainly address these issues, but only after a number of individuals have flagged the offending content. Returning to my example of the five-year-old holding a mobile phone, that child’s parent might not feel that a “flag as inappropriate” link was adequate in this context.
Back to Daisy Garden. In addition to these constraints, sharing necessitates that there is something worth sharing. Further to this, if you want people to share across cultural boundaries, it has to be something universal, something that everyone can appreciate. This is what led me to the idea of flowers, and gardens.
And I’m not as authoritarian within Daisy Garden as the observations above might suggest - where individuals share outside of the application, I’m much more relaxed - for example, users can name their flowers when they share them with others. But now that I’m beginning to add features that will allow users to share their garden designs with all other users of the application, I’m very glad I considered these things before I released the early versions of Daisy Garden.
P.S.
I did want to post/tweet this under the title “How to keep your application genital free”, but didn’t want to offend anyone.
After my previous post comparing Java’s regular random number generator to its cryptographic SHA1PNG relation, Benjamin Manes suggested using double-hashing has a way of generating multiple and provided an implementation for me to test.
The initial results appear to be excellent. It yielded by far the shortest test time (approx. 4s compared to 18s for the standard Java random number generator) and in this limited test exhibited a distribution that is almost indistinguishable from that of SHA1PNG.
