If you’re into reloading, you know about chronographs. Odds are you might have a Shooting Chrony. I myself happen to own a Shooting Chrony Beta Master. These are pretty well made devices, and Shooting Chrony has a no nonsense replacement policy.
The only way to interact with the device is via a proprietary 9-pin-female RS-232 cable, like an old modem. Now, this techique was all the rage circa 1994 when dial-up internet was king and everybody had PC’s with two or more serial ports. This is really sub-par when you want to try and connect your smartphone to a Shooting Chrony (yes, this is possible, but more on this later).
I recently bought some Estimote beacons (a 3rd party iBeacon-like device) - largely because they seem like a cool and nerdy kind of thing. It has an Android SDK which will allow Android devices to interaction with devices. With a little big of effort, I managed to create Xamarin.Android binding and port the sample Android project provided by the Estimote SDK.
You can see an example of the app in these screenshots:
A visually pleasant effect when deleting items from a ListView is to animate the row being deleted by gradually change the .Alpha value of the view from 1.0 to 0.0. If you’ve tried to animate the deletion of a row from a ListView in a Xamarin.Android application, you may observe some curious behaviour when rapidly scrolling through a ListView with many rows: the animation may appear on rows other than then one that is being deleted.
One of the handy things about the JPEG format is the ability to store meta-data inside the image using EXIF. There are a few libraries out there for the various programming languages that can help you out with this, and Android actually has something built in to the SDK - the class ExifInterface.
Google’s documentation on writing latitude and longitude to a JPEG are a bit light on details - they loosely hint at the format that latitude or longitude should have. (See the documentation for ExifInterface.TAG_GPS_LATITUDE). The API itself is pretty straight forward, but what Google doesn’t tell you is HOW the GPS coordinates should encoded.
Deploy early, deploy often is a popular goal in Agile methodologies. One easy way to support this to automate your build process. Last year at this time I would just use FinalBuilder to automate the builds of my Xamarin.Android pet projects. It doesn’t take much to set FinalBuilder, and it does provide support for a lot of tasks such as versioning .NET assemblies, manipulating XML, dealing with the file system, and so on.
The problem is that FinalBuilder is Windows only. OS X and Linux types are left out in the cold. As I find myself working almost exclusive in OS X when developing my Xamarin.Android applications, I was looking for a Windows free way to automate my builds.
Enter rake and albacore. rake is, of course the build system for Ruby.
Setting up a new VM for development - this one based on Windows 8 64 bit. Not that I really want to, but it seems that I need to for work (yes, yes, first world problems). So the usual fun with standing up a new VM:
Of course, then I notice that my phone, a Galaxy Nexus, isn’t being recognized by Android Debug Bridge. This is a problem as I much prefer to develop using a device as opposed slow emulator that Google ships for Android, and you can’t deploy to the device without ADB.
One of the new classes that Honeycomb introduced was the PreferenceFragment. This class is meant to simplify the creatation of a setting / preferences screen in Android applications. It handles a lot of the displaying, saving, and changing of an application’s settings. There are a couple of ways to create a PreferenceFragment. The simplest way is to subclass, override onCreate() and then use either getPreferencesFromResource or getPreferencesFromIntent.
There are many examples on how to use getPreferencesFromResource, but I noticed that there aren’t that many on how to use getPreferencesFromIntent. Here is one such quick example.
