Vagabond 1.0 – Nearly Here

Yes that’s right. After much toil, and missing my self-imposed deadline for a release, I’m nearly complete with the program and can give it a 1.0 which means that it’ll go into General Availability.

I’m not posting Vagabond News on its website because I want that strictly to be a place to get the program from and a reference for information that developers would be interested in. Just wanted to get that out of the way as well. 🙂

Right now the program is about 98% done. All that remains is to test two additional features, push to the repository (assuming they work, which they will) and then build Debian, RPM and Source Taballs for deliverables. I haven’t built Debian packages for quite some time so I’m having to go through several refreshers to bring myself back up to speed on the workflow.

After this release, I have some additional features I want to work in so development will continue alongside general maintenance coding. I want to be able to add support for choosing to use either the official Android SDK or to use the Replicant SDK. This is more of an ethical decision as I feel like Replicant is a great choice for developing in an open-source manner but might not be the best idea if you’re writing Android to be published on Play. But the option should be there. I’m also considering the idea of implementing SDK Administrative Task Shortcuts. These are commands that can be passed to Vagabond that will inflate to more robust tasks passed to the VM that maintain the SDK.

If all goes as planned, and work and life leave me alone long enough, I can potentially have this ready to go by the end of the week.

Development Journal – Smsr Update 001

I’d like to think that I started working on a rough draft with Smsr and then it evolved into something else.

This “rough draft” had a bit of code in it encapsulated in an entity called ConversationThread. A function of this class in particular was really nasty since what it did was take all of the SMS messages on the device and effectively organize them in a cohesive manner that didn’t rely on querying sub-providers like Sms.Inbox or Sms.Sent. The reasoning behind this was that when I would query some of the more specific Content Providers, like Sms.Conversations, the Cursor returned from that query would only contain three fields regardless of the applied projection. In other words, despite the fact that the contract class inherited from base interfaces that gave it the additional fields you’d want, this inheritance doesn’t apply to what’s returned from queries against the provider because these columns are missing from the Cursor. So it wouldn’t contain things like ADDRESS or _ID. And because these Content Providers weren’t designed with the ability to perform SQL Joins via queries (despite the fact that the documentation would lead you to believe so), the only other alternative, really, is to perform several separate queries against several different Content Providers and join them using either MatrixCursor or CursorJoiner. The issue there is (A) how to do this without blocking on the UI thread and (B) because subsequent queries would rely specifically on information that was contained in previous queries, how then to make sure that the queries had completed before attempting to use them?

I really tried to avoid the solution where multiple queries were involved because it just seemed so… lackluster. Not to mention that the idea of tossing back and forth between five or six Cursors seemed like an explosion in the works. But there was a major issue with the way I was doing it originally – real-time updates. Because the backing data was effectively abstracted into this seemingly convoluted construct that didn’t directly bind to the backing data, if something changed in the data (i.e. received a new text message), the structure would effectively have to be completely rebuilt. One pass on building that thing was expensive enough since it relied heavily on Collections. Doing it over and over again could lead to some really janky issues.

So I went back to the drawing board. And what I came out with, after struggling for a bit to understand MatrixCursor, was a solution that does in fact query multiple Content Providers which will yield several Cursors and then combines them into a MatrixCursor which is then given to my custom CursorAdapter. The result here also adds to a modified layout for the Conversation Stubs which uses a LayerDrawable to get the contact’s image (default if none) and apply a gradient over top of it that leads to the other half of the list.

Unfortunately, this change has broken the Activity that will show the Conversation Thread because the data that’s now contained in the stubs is different than what that Activity was looking for in the first place. But the stub viewer looks nice! 😀

If you want to follow along, the branch that this work is being done on is the “rewrite” branch.

https://github.com/gregfmartin/smsdemo/tree/rewrite

Development Journal – Smsr

The SMS client that I’ve been working on for Android is now being renamed to Smsr (even though the root directory of the project will still say sms_demo).

I’ve uploaded the source code to Github so feel free to take a look at the source, fork or do whatever the hell you want with it. I’m going to be updating the contents of the wiki and the project landing page as major changes are made to the upstream build.

http://gregfmartin.github.io/smsdemo/

Development Journal – Android SMS App

For the longest time, I’ve been wanting to write a SMS app for Android. The issue originally (and still is unfortunately) was that if you’re running a device that has a version of Android less than KitKat (4.4.x), a programmer doesn’t have access to native public-facing APIs to get access to these Content Providers. Instead you have to rely on the Reflection APIs to poke around for them and, if they’re there, use them that way. It might not seem like it at first but Reflection can be a bit heavyweight on more resource-constrained devices (which can potentially toss ANRs or even cost battery cycles) and also makes for some really nasty looking code. I’ve worked on several projects where Reflection was the order of the day (especially for things like accessing Enterprise Configurations in WifiManager) but unless I really had no other choice, I tried to stay away from the Reflection solution as much as possible. Even going to the lengths of not writing this SMS app I wanted to do for so long because there wasn’t a public API for it. Enter KitKat with these packages and now I’m going to town.

Putting aside the fact that Google likes to arbitrarily break your code with new upstream versions, the package that contains the contract classes for these Content Providers, android.providers.Telephony, is actually quite solid. Unless they go ape-shit on this package like they did with ContactsContract (which is an absolute fucking nightmare to work with), we should be okay for the time being.

I’ll save the technical discussion for another post (or even a video) but what I wanted to do here was showcase the current state of the build that I have for the SMS app. Honestly I’ve spent more time trying to figure out the nuances of the contracts and how to use them and fucking around with 9-Patch than anything else (9-Patch is cool technically but why can’t someone at Google make decent documentation?) Additionally, I wanted to provide a tentative roadmap for where this is going.

A listing of all Conversation Stubs
A listing of all Conversation Stubs

Here’s a screen capture of the home screen which will display what I refer to as the “Conversation Stubs.” No, those aren’t native constructs in Android, it’s a custom object that I’ve built for this app. The goal here was simple – after doing all the magic necessary to sort the messages to have them make sense, grab the most recent one and from it derive the contact’s display name and a 45-character snippet of the message body. If the snippet length equals 45-characters, an ellipsis is appended to it to indicate that there’s more to the message than what’s visible. What’s missing here is an indication that the message was sent from you to the intended recipient (coming in the next nightly build). By the way, I swear I didn’t plan the colour of the ActionBar to match that of my site. 😉

Pressing on one of the Conversation Stubs will bring you to another screen which will display the entire Conversation Thread.

A Conversation Thread listing
A Conversation Thread listing

As with Conversation Stub, a Conversation Thread is not a native construct to Android. Now if you’ve done a little digging into the package yourself, you might be thinking why not just use the Conversation Contract? I’ll do more on that in the technical discussion.  Although there are no clear visual cues as to who said what, messages that have been sent from you to the recipient are on the right side and messages from the recipient to you are on the left. Each message is time-stamped currently using 24-hour format (this will be customisable in a later build). The thread recipient’s display name occupies the ActionBar in the top-left. The list of messages is sorted in descending order from the top and will automatically start from the bottom when opened which will display the most recent messages. Right now, there’s not much else here other than what you see.

 

Current, if short, Preferences
Current, if short, Preferences

The last point of interest here is the slowly building Preferences. One of my targets here is to have a decently high level of customisation while still retaining the overall look-and-feel of the app that I want. The bottom option is the more interesting one right now. As I mentioned before, KitKat will allow a user to specify an app to be the dedicated Messaging app. Of course I want the user to be able to choose this one as the default if they wish to do so. Pressing this brings up a dialogue that will allow you to choose the default app.

Overall, the goal here is quite simple. I prefer as vanilla of an experience on my Android devices and I like the Google Play Services and default apps but I have a serious beef with Hangouts. It just feels too clunky and I wanted something a little more back-to-basics. The current build cannot actually compose or send SMS yet (coming in two builds) nor can it determine or store draft messages (coming in a build after the previously mentioned one). MMS is also not yet handled but is coming shortly. I do not want to do anything fancy like integrate with Google Accounts like Hangouts does. I want this to be a pure unadulterated SMS/MMS experience. Nothing more.

Some tentative features that I have in mind though are sticky messages, cherry-pick deletion, hidden threads, export a conversation thread to a file (I’ve actually had a lot of interest in this from some clients for legal reasons) or print a conversation thread directly to a printer (relies on Android Print Services) or email a conversation thread to an email address, bulk messaging (one-to-many) and group messaging (many-to-many).

I’ll do a technical discussion on how to use the SMS Contracts and all of the nuances that I’ve discovered with them soon. Either way, I’m looking to have a first version published by the end of the month.

Sometimes, Silence is Bronze

I have officially gone under a rock.

Most of it was my fault. I gambled (in an ethereal sense), I lost (more than just money mind you) and now I’m paying for it. So-to-speak anyway.

So the things that I have been working on – LinuxInstall and WIPN for example, have been without my presence for some time and may continue that way for just a bit longer.

That doesn’t mean I haven’t been busy and working on things in abstentia.

All I’m going to leave here is this single image.

The Oily Cow

Fedora 19 Release

This fell off my radar since I’ve been dealing with a death in the family. But I wanted to summarize the important notes that are provided regarding the latest release from Fedora that pertains to both desktop and power users. I’m still working on a full review which I’m going to modify some since most of that information was based off of the alpha and beta RC releases.

Fedora 19 can be downloaded from the typical page on their website.

Fedora 19 has several desktop environments available including the well established GNOME and KDE. However more focus is being brought to the inclusion of Cinnamon and MATE. So for those of you who are interested in the spicy goodness or retaining the pseudo-GNOME2 interfaces respectively, you can get your fix. Having spent a little time with Linux Mint 15, and assuming that this is the version that Fedora is pulling from (I haven’t been able to verify this yet), Cinnamon is definitely worth a look if you want a modern UI without sacrificing all that GNOME3 requires you to. I’ve personally never been able to get into MATE but some people prefer that type of traditional computing experience. I’m still going to stick with GNOME3 though. 🙂

Speaking of GNOME3, one notable enhancement which, frankly, should have made it in far earlier than now is the inclusion of RAR archive compression/decompression with File Roller. Now we can all open those RAR archives natively in a seamless UI experience without having to go looking for the appropriate package to do this.

There are also the visual enhancements in GNOME3 as well that were noticeable in the alpha and beta RC releases. I think the thing that really stands out for me right now is the new icon theme that’s released by default. I’ve always had this problem with how the GNOME-themed icons looked. They looked nice in the GNOME2 days but appeared to be severely neglected and just didn’t age well. I’m not sure if someone just didn’t care or didn’t have the time to work on them. Anyway, there’s been an improvement and I’m impressed. There’s still a bit of a daft feeling to them but the overall presentation is much better.

Of course there are going to be software improvements across the board and LibreOffice is no exception. Fedora 19 is rolling out with version 4.0 of the now de-facto open-source office suite. There are a swath of changes in this latest version but the one that I’m most interested in is the improved support for the import of Visio and Publisher documents and the ability to collaborate using the CMIS standard. This allows LibreOffice to integrate or interact with CMS and cloud document storage systems (Google Drive, perhaps???). All of those changes can be found at the release notes page here.

I’m still trying to parse the changes relevant to sysadmins. Unfortunately I haven’t had an opportunity to install the 19 stable release yet (I will tonight) so I can’t make any comments on any changes that were potentially made to anaconda. I’m hoping there were some. I clearly remember some ambassadors making a remark similar to “if you just read what’s on the screen, you shouldn’t have any issues.” That’s all fine and dandy but when I’m reading what’s on the screen and I’m still getting a little fuzzy as to what’s required of me, there’s a problem. Trust me when I tell you that I understand partitioning; I’ve been doing it for years. “Worked fine in dev, ops problem now” is not an acceptable excuse.

From a 30,000′ view, it looks like there have been some modifications to Active Directory integration, the inclusion of an alternative bootloader intended for minimal cloud deployments (extlinux), minor visual improvements to GRUB and a decent amount of work on the system daemons and cloud integration technologies like OpenStack and OpenShift (known as Origin in Fedora as it’s a community variant of Red Hat’s OpenShift product).

A program that was included that I’m interested to see is called Scratch. Supposedly it’s a catch-all development environment that enables RAD for interactive stories, animations and games. This looks similar to what Alice did years ago but it’s definitely geared toward a far younger audience. I’m curious to see if this would have any educational impact on teaching younger students the value of logical thought processes though software development. Or just how much fun you can have while doing it. 🙂

Of particular interest to me, being an Android/Java developer, is that Fedora 19 has the packages for the technical preview of Java 8 (through OpenJDK). There are some pretty hefty changes coming in the next version and I can build my programs against this version to see if they break or add functionality that’s specific to 8 and see if I screwed anything up. This won’t matter too much to Android development specifically but some of my desktop programs would benefit from this. Seeing as how these were integrated already, once the stable branch of 8 is released, those packages will be updated respectively and we can get them as soon as they’re available. I don’t have an ETA for the 8 stable release. I’ve seen scuttlebutt that we’re not going to see it until 2014 but who really knows.

Anyway, I’m going to download an ISO and fire it up when I get home. By the end of the weekend, I should have a pretty decent amount of fuel for the full review.

Weekend Coding – Session A (Audio Version)

This is the audio-only version of a video that I’m currently waiting for YouTube to process called Weekend Coding. This is my attempt at archiving my “developmental evolution”. I’m not intending it to be for entertainment purposes but if you do like it, that’s cool.

This session starts with some musings on my qualifications as a bedroom coder. Then I move into analysis of the code that I’m writing (Android using IntelliJ). There are tracks playing in the background from Jamendo and those tracks are referenced on the SoundCloud page for this.

Once YouTube decides to let me have control over the video, I’ll post a link here as well.