Skip to main content

android development on windows 8, step 2

I started the month of May off with a simple post about developing for Android on Windows 8. I'd made a Big Promise to do a lot more than I've actually wound up doing. It's not that I've given up, it's that an awful lot has happened over the last 31 days. I did do some more development, less than I certainly anticipated, but I've not completely stopped. I'm just going at a slower rate than I anticipated.

One of the better ways to dive and and get to know any complex software system is to take code previously written against an older version of an application and port it to the latest release of a compiler, software framework, operating system, or other complex software environment. Every complex system provides code examples to illustrate features and capabilities and to act as a starting point for other developers. And every example is always written against the earliest release, and more often than not, is never revisited and brought up to date against the evolving compiler, software framework, operating system, or other complex environment.

In order to advance and still allow older written software to continue to work, some systems (such as Java) will publicly deprecate a given interface but still allow it to be compiled with older applications so they can continue to work. Ideally as a developer you're supposed to note the deprecation warnings that come from a compiler (command line) or integrated development environment (IDE) and to correct them. In a dynamic and evolving software environment public interfaces can become deprecated because the creators discover better functional and/or faster ways to deliver a service behind the interface. Creators always (mostly) try to add value with an existing interface, but when that's not possible, the older interface is deprecated, a newer better one is created, and documentation is updated to point out how to use the latest interface that replaces the deprecated interface.

Of course, the question is always asked, "When is the deprecated interface dropped completely?" And the answer, unfortunately, is usually "Never." The motivation to use the newer interfaces isn't that older interfaces will be dropped, but that no further work will be done on older interfaces. All the development and bug fixes go towards the latest and greatest. Old and deprecated is allowed to rot. And if you don't update your software, it suffers from that internal bitrot.

In the example above I opened one of the early Android projects, NotesList. This is part of the collection of example applications that are delivered with the Android SDK. I created a new project with NotesList, and started to open the source files and look at the warnings generated within Eclipse. One of the deprecated warnings was against That deprecation forced me to replace one line of code with four, using the following recommended steps:

CursorLoader cursorLoader = new CursorLoader(this.getApplicationContext());
mCursor = cursorLoader.loadInBackground();

The key being the replacement of managedQuery(...) with essentially CursorLoader.loadInBackground().

It took several attempts to find the exact invocation for the creation of a CursorLoader instance. The Android documentation was a bit vague as to correctly obtain the correct argument. My first creation of a CursorLoader was new CursorLoader(this). It compiled just fine and the emulator even started up, but after several moments of testing the emulator core dumped (crashed). I went back and re-read the Android SDK documentation a bit further and on a hunch (or guess, take your pick) created new CursorLoader(this.getApplicationContext()), which is what the documentation was trying to ask for. It was interesting that the bare this reference was accepted as a type of ApplicationContext, or at least the IDE issued no warnings.

In any event it worked and I've been "fixing" other deprecation warnings. The only problem with just blindly fixing deprecation warnings is you miss the bigger design picture. APIs are created and used in a larger architecture and design context. Just because I fix the warnings doesn't mean that their use is now considered best practice at this point in time. Keep in mind that Android first started as an OS purely for handsets. Then, starting with Android 3 (Honeycomb), Google started migrating to tablets. The migration wasn't complete until Android 4 (Ice Cream Sandwich) and beyond. Some best practices for handsets didn't transfer all that well to tablets. That's why Google refused to release the code for Honeycomb; Honeycomb was a right royal hack with bad API juju all over the place to support the initial sale of Android tablets such as the Motorola Xoom. Google wanted a chance to release new and updated public APIs with decent implementations that were worth supporting in the future before they turned the code completely loose.


Popular posts from this blog

cat-in-a-box channels greta garbo

So I'm sitting at my computer, when I start to notice a racket in back. I ignore it for a while until I hear a load "thump!", as if something had been dropped on the floor, followed by a lot of loud rattling. I turn around and see Lucy in the box just having a grand old time, rolling around and rattling that box a good one. I grab the GX1 and snap a few shots before she notices me and the camera, then leaps out and back into her chair (which used to be my chair before she decided it was her chair).

Just like caring for Katie my black Lab taught me about dogs, caring for Lucy is teaching me about cats. She finds me fascinating, as I do her. And she expresses great affection and love toward me without coaxing. I try to return the affection and love, but she is a cat, and she takes a bat at me on occasion, although I think that's just her being playful. She always has her claws in when she does that.

She sits next to me during the evening in her chair while I sit in mi…

vm networking problem fixed

Over the weekend I upgraded to Windows 8.1, then discovered that networking for the virtual machines wouldn't work. Then I tried something incredibly simple and fixed the problem.

Checking the system I noticed that three VMware Windows services weren't running; VMnetDHCP, VMUSBArbService, and VMwareNatService. VMware Player allows you to install, remove, or fix an existing installation. I chose to try fixing the installation, and that fixed the problem. The services were re-installed/restarted, and the virtual machines had networking again.

Once network connectivity was established there was exactly one updated file for Ubuntu 13.10, a data file. This underscores how solid and finished the release was this time. Every other version of every other Linux installation I've ever dealt with has always been succeeded by boatloads of updates after the initial installation. But not this time.

Everything is working properly on my notebook. All's right with the world.

sony's pivotal mirrorless move

I'm a died-in-the-wool technologist, even when it comes to photography. I have always been fascinated with the technology that goes into manufacturing any camera, from the lenses (optics) through the mechanical construction, the electronics involved, and especially the chemistry of the film and the sophistication of the digital sensor. It's amazing that the camera can do all it's asked of it, regardless of manufacturer.

Of all the types of cameras that I've really taken an interest in, contemporary mirrorless (again, regardless of manufacturer) are the most interesting because of the challenging problems the scientists and engineers have had to solve in order to build a compact but highly functional camera. In particular I've followed the sensor advances over the years and watched image quality climb (especially with μ4:3rds) to exceed film and rival one another such that there's very little difference any more as you move from the smaller sensors such as 4:3r…