Due to the amazing interest shown in my ICS Reader app for Android, I have decided to actually release it! For now, here is the APK of ICSReader.
I may well release the code, but I’d have to have a quick look through it first.
Just a quick reminder, as much for myself as for my readers – Oracle has released Beehive 2.0.1, which I will be looking at in about two weeks, to see if it will be able to replace our current Collaboration Suite Calendar installation. Sadly, it still seems like Oracle insist that you must use their inferior email server to use the rest of the system.
After having ranted quite a bit about the lack of support for standards-based calendars and PIM in Android, I decided to implement something myself, to at least get it to a level where an Android phone would be of use to me. Since we have a functioning iCalendar export from our Oracle Collaboration Suite calendar at work, I decided to start out writing a parser for that. ICSReader is the result.
The software does a bit more than just read iCalendar files by now, and since it’s reached the critical junction where I want to expand the functionality significantly, the time has come where it gets its very first version number: 0.1
The very first version, 0.1, has the following features:
More importantly, it lacks the following features:
The observant reader will have noticed that I have yet to provide a link to this software. Currently, it’s only been built for Android 2.0, and while it may serve a purpose for some people in need of an iCalendar reader, it is not yet sufficiently polished for me to feel comfortable in publishing it. If you happen to need it, post a comment, and I might well reconsider and post a usable build. Otherwise, I am going to work towards a new version with at the least support for multiple iCalendar sources before releasing it.
Got some new features you really want in an Android calendar application? Post a comment, and I’ll have a look. 
Update: I released the app.
I’ve been writing a bit more Android code, and came upon the need to write a custom CursorAdapter for a ListView, as the way I wanted to display data from a Cursor was dependent on relationships between different fields of the database.
Of the problems I encountered, the most obvious was when I tried to inflate views using View.inflate(), and found I would get the following error:
UnsupportedOperationException: addView(View, LayoutParams) is not supported in AdapterView at android.widget.AdapterView
After a bit of rummaging around, I found that the following bit of code would work when attached to a ListView using setAdapter().
public class ExampleCursorAdapter extends CursorAdapter { public ExampleCursorAdapter(Context context, Cursor c) { super(context, c); } @Override public void bindView(View view, Context context, Cursor cursor) { TextView summary = (TextView)view.findViewById(R.id.summary); summary.setText(cursor.getString( cursor.getColumnIndex(ExampleDB.KEY_EXAMPLE_SUMMARY))); } @Override public View newView(Context context, Cursor cursor, ViewGroup parent) { LayoutInflater inflater = LayoutInflater.from(context); View v = inflater.inflate(R.layout.item, parent, false); bindView(v, context, cursor); return v; } }
The above example code doesn’t actually require a CursorAdapter, it would easily be implemented using a SimpleCursorAdapter, but it serves to show the idea. Basicly, get a LayoutInflater from the context, and use the version of inflate() that does not attach to the root view.
I’ve just released version 0.3 of Xydroid, my small Xymon monitoring app. It should now be a bit more suited to Android 2.0, and have just a couple fewer bugs in it.
As it turns out, the main problem with running under Android 2.0 for my app was de-parceling of a Parcelable representation of the XML files used by Xydroid. Up until now, I had just written out all the data in the tree when parceling, and read until no data was left when de-parceling. As it turns out, if this parcelable class is put into a bundle with other data, such as strings or integers, the de-parceling code will just continue reading along the bundle. The error I tended to encounter would be “Unmarshalling unknown type code 6946932″ (or some other number), presumably as I tried to read a String from where an integer existed or similar.
The solution seems to be to write how much data you are planning to parcel as the first bit of information, and only read back this many chunks before passing control back. This works both in 2.0 and 1.5/1.6, whereas reading until there was no more data seemed to work in 1.5/1.6 but not 2.0 — though this might just have been pure luck.
Update: I thought I had better actually show how I ended up implementing my Parcelable classes, so here is a quick example of how to wrap a HashMap in something parcelable:
Read the rest of this entry »
When I noticed the Android 2.0 software development kit had been launched, I hurried up and installed it. Okay, it did take the better part of 5 hours before it was properly installed, as Google’s servers were probably overloaded. None the less, I managed it at least, and fired up an Android 2.0 emulator, taking a moment to marvel at the fancy new settings that have been added for creating AVDs, before hurrying on to install my app, Xydroid.
As usual, it exhibited the crash right at first time start, probably as both the main thread and the update thread try to create the database, and they step on each others toes. I’ll be sure to get that fixed any day now. Somehow.
There’s also a new crash, though — this one is right after adding a new source, where the app tries to launch an activity that lets the user select the services to monitor. This gets a runtime error with a null pointer exception, whereas launching the activity separately, after the source has been added works fine. This could be a change in the way bundles between activities are handled in Android 2.0 versus 1.6.
I will probably have to get my act together and release a version 0.3 with these couple of bugs fixed, as well as plenty of testing done for differing screen sizes. One of the great advantages of Android can be said to be the number of different devices you can use it on — and it’s one of the major drawbacks as well, as there will always be a lot of different things to consider when designing the user interface. I do still prefer it over the iPhone, though
A short while ago, I asked what Google were going to do with PIM in Android. Now it seems there’s an answer, or at least part of it, in the release of the Android 2.0 SDK: They’re going to support third party adapters.
The nice people at Engadget have a summary of some of the changes, and among them one can find:
Hopefully, this means they’re actually going to start working on some nice built-in adapters as well, but at least it seems they’re opening up the sync parts of the platform from 2.0, contrary to what had earlier been reported. Yay.
From the early days of palm-top devices, through early smartphones like the Nokia Communicator, and up to all the iPhones, Androids and BlackBerrys of today, what the serious users have been looking for has always been PIM: Personal Information Management. They are looking to have their email, calendar, contacts and notes available at all times, on a small portable device. Indeed, as am I. I have been using my Nokia N95 for a couple of years now, and there really is something to be said for having my calendar with me at all times, just by the virtue of carrying my phone.
So what have Google done with Android? They’ve put Google Mail, Google Calendar and a Contacts synchronization to Google Mail in their fine mobile operating system, which goes some of the way. They have also, I am told, put in a regular IMAP client, for those people who don’t use Google Mail, for instance for corporate email. But, it seems, the fun ends there.
There’s no direct support for SyncML, and nothing, it seems, for Exchange. Sure, you can go through Google Calendar for your calendar syncs, and I presume you can forward your mail to Gmail – if your corporate policy permits that. But when it comes to direct sync for third party providers, no luck.
It’s starting to look a bit like what some of us have criticized Apple’s software for doing: If you don’t use it like Steve Jobs does, you’re out of luck. In this case though, even more so: If you don’t buy into Google’s services, no luck with Android’s default apps.
So someone could just develop a sync adapter for the built-in calendar. The source is available under the Apache license, so why not? Here’s why: Google have stated that the API for the built-in Calendar is not public and not going to be for 1.6 or 2.0, which leaves a worrying question: Are Google only going support their own services from the base OS?
It’s certainly not completely unthinkable, as Android has been hailed as an open platform, so anyone can just code a Calendar app, right. Right? Well, maybe. But selling smartphones with no proper PIM solution for anything else than a single provider doesn’t seem like a viable business to me, and I really do hope Google make up their mind to do things differently, and support direct over-the-air synchronization with SyncML, CalDav or even Exchange systems.
Finally, an update for the blog! Well, what has been going on with me? I’ve been busy at work, and perhaps even busier with my studies. I’m currently doing a course on Concurrency, which got me started on a bit of lovely threaded java programming again. It’s nice to be back to writing a bit of code, and boy have things gotten better over the few years since I last did anything major with it.
In other news, a couple of friends have bought themselves new Android phones, the HTC Hero. More and more of them are coming now, and it really looks like a wagon I’m liable to jump on any day now. They just need to release a new revision of the hardware, preferably something with one of the new Snapdragon CPUs in it …
So what could be more logical than to do a bit of programming for the Android platform? I struggled for a short while to figure out anything worthwhile to write, but then I came up with this: How nice would it be to get the status of your monitored systems direct on your phone? No more needing to browse to the hobbit Xymon system now, just a look at the phone to see how everything you care about is doing. Well, in theory. Except I don’t have the phone yet. Slight flaw in the plan.
None the less, I’ve made the software, in a sort of early beta version, and it’s available on a webpage of its own: Xydroid. Feel free to have a look .. if you want to actually use it, you should probably get in touch, and I’ll be sure to work on it enough that it will actually work properly as well.
After I’d started writing the software – actually, after I’d gotten quite far in the process – I found out that other’s have actually done the same as well, in the form of Xymon Monitor, for which they charge €2.99. Well, at least this might end up as the slightly cheaper alternative
The directory server we use at work is a Fedora Directory Server installation, running 4 nodes in a multi-master setup. We’ve been looking into migrating it to a Sun Java System Directory Server Enterprise Edition (sic) for a while, since I returned from the course in the US, but I haven’t had the time to get a proper test installation running yet. With Beehive 1.5.1 out, and given my enthusiasm for that, I decided to try and see if it would work with the Fedora Directory Server, even though it wasn’t supported.
I went with the template for synchronizing a Sun directory, as my sources had told me the two were very similar, in fact originally from the same source tree. The templates are pretty readable, but have manual handy for checking what some of the stuff means. One caveat: The attributes in the template are generally written like this:
<profile_name><enter profile name here></profile name>
What they expect you to write, is something like this:
<profile_name>Test profile</profile_name>
The extra angle brackets are just put there to confuse us 
My main concern at this point was that while I could define specific attribute values to mean external mail or not, it didn’t seem like this could be set merely by the presence of absence of attributes. I may have to re-think the directory structure slightly to address this.
When I added the profile using beectl, it turned out not to validate. Beehive was unable to find the directory server changelog. As it turns out, Beehive relies on an “old-fashioned” approach to synchronization between directory servers, and in fact one that can be enabled using a “Retro Changelog Plugin” for the Fedora Directory Server. So, if you’re on Google, trying to figure out how to make Beehive work with Fedora Directory Server: Use the Retro Changelog Plugin!
After setting this up, things seemed to just work. Now, there’s another little caveat: Beehive works with a concept of “principals”, that are your login credentials; In the default case your email for login and for instant messenging, and your phone number for voicemail. I changed the mail principal to be the user’s UID, but left them for IM and voicemail – meaning some users weren’t imported into Beehive, as it insists on the attributes used for this (mail and telephoneNumber) being unique in the directory. We have people who rightly have the same telephone number, for instance sharing an office, and Beehive doesn’t seem to like that. My idea of how to handle it: Make seperate attributes for voicemail-principals and instant messenging principals if you’re going to need those things, or disable them in the sync profile.
I would rather like for all our users to have an instant messenging principal that’s their UID @ some domain. I haven’t been able to find the option for it yet, and I’m not sure if it exists at all … if you know it doesn’t, and you’re a Beehive developer: Go fix this!