For some time now, my PCDB Waypoints app has been failing to retrieve map tiles from the default OpenStreetMap server MapNik.  It looked at first as though the problem was with the app, but after lots of investigation it became apparent that the issue was rather more deepseated.  Deep down in the OpenStreetMap website is a statement that OpenSteetMap.org can block apps that appear to be making excessive demands on their servers.  Thinking that PCDB Waypoints may have been blocked in this way, I looked for alternatives and found one in MapQuest.  Tiles from that website displayed OK, so obviously the app software wasn't at fault.  However, although MapQuest says that is uses tiles from OpenStreetMap, this isn't actually the case and some of the finer details from OpenStreetMap (such as lighthouses!) was missing.

Further investigation in OSMDroid itself turned up the news that it wasn't PCDB Waypoints that had been blocked by OpenStreetMap.org, but a widget called the Apache HTTP Client.  This is used by default in all OSMDroid apps, and it was the cumulative effect of all OSMDroid instances that was overloading OpenStreetMap and which had been blocked.

Even further investigation disclosed that this issue had recently been addressed by OSMDroid, and a fix (Patch 515) was available. The effect of this was to put a string such as "osmdroid(PCDB Waypoints)" in each HTTP call, so that OpenStreetMap could differentiate between all the various OSMDroid apps out there in the market, and only block those that were truly at fault.

However, this fix wasn't available in the latest OSMDroid download (Version 4.0), and I could only apply it if I could get hold of the source code and incorporate this into the app.  There's nothing wrong with this; it's an integral part of the OSM philosophy that developers should be able to do this, and it's perfectly easy to download a .jar file containing all the source code of Version 4.0.  It's something I've been planning to do for some time, but to date I've always been able to make changes by including individual top-level code and adapting it as appropriate.  The code affected by Patch 515 is deep down in the workings of OSMDroid, and I couldn't apply the patch without downloading the whole caboodle.

Downloading it was one thing.  Incorporating it into PCDB Waypoints was another, and took a large part of today.  But eventually I managed it, compiled the app, installed it on my tablet and checked that I could use the MapQuest tile server OK.

Once that was achieved, I could then apply Patch 515, compile it, install it, and Hey Presto! MapNik tiles started to display again.

A very satisfactory outcome.

As I indicated above, I've been incorporating modified versions of some OSMDroid code into my app for some time.  Now that I've got the whole development working, I can start making these available to other users if they're interested.  For example, there's a version of IconOverlay that has a "MinZoomLevel" parameter, so the Icon isn't displayed at low zoom levels.  And a version of ItemizedIconOverlay that exploits this feature.  There are similar extensions to PathOverlay, a Lat/Lon grid overlay, and others.

When I first developed the Android version of SuDokuSolver, it was derived from a Windows-based, mouse driven version which had been running for some years.  The first thing I noticed when I started to use the Android version "for real" was that the screen was the wrong way round.  As it was touch-based, touching the buttons on the left hand side with my right hand obscured the working areas in the centre and right, and that what I needed to do was reverse the order of these three principal screen areas.

However, instead of doing just that, I reasoned that I already had a version that was suited to left-handed people, and it seemed a shame to throw that away.  So I introduced some alternative screen layouts for right-handed users, and a menu-driven facility to switch from one to the other.

I recently managed to break my right wrist and elbow rather badly, and for the last few weeks I've been in plaster from the hand to above the elbow.  I've used the enforced idle time that this has generated (I should have been sailing for six weeks by now) to work my way through the pile of Sudoku and Killer Sudoku puzzles I had waiting to be processed by Sudoku Solver.  Using the Left-handed facility, of course!  It's worked a treat.  I've also taken the opportunity to make some changes to the layout XML files to bring them more in line with the latest Android standards.  I'll make a new release of both Sudoku Solver and SuDoku Lite when the plaster is off my elbow and I can type normally again; at present I'm restricted to using just one finger on my right hand.

However, though the left-handed facility worked just fine, I did notice one issue: my ComboBox widget had the drop-down button on the right-hand, so the text in the ComboBox was obscured by my left hand when using that button.  So after digging around in StackOverflow and other useful Android support sites, I've found a way to implement a layout parameter that enables me to specify whether the dropdown button should go on the left or the right.  This is now working, and by introducing left-hand variants of the Select Game and Save Game functions I can use this left-handed ComboBox in those variants. This will be in the next releases of SuDoku Solver and SuDoku Lite.  I'll share that ComboBox code via this website, again when my elbow is better.

The biggest struggle I've had with mapping in PCDB Waypoints is in drawing the grid lines.  The literature here is very skimpy, and in particular it's not easy to work out what pixel co-ordinates to use to draw something on the portion of the map that is currently on display.  But with the help of a few useful posts on Stack Overflow, I've managed to put together a class called  GridOverlay which extends Overlay and works with maps supported by OSMDroid.  OSMDroid is an alternative to the mapping facilities provided by Google Maps, which are limited to use with only maps provided by Google.  (Goodness knows what Google hope to achieve by that limitation.)  OSMDroid facilities aOverlays are usually used to draw markers of various sorts on the Map.  GridOverlay doesn't store any markers, or Points (as PathOverlay does), and doesn't have any onTap methods.  Instead, it contains a few getters and setters, and a draw() method which does all the work.

You can find the java code of GridOverlay here.

The draw() method calculates the grid size, aiming to get a minimum of two latitude lines within the MapView's current display area.  It draws the grid only on the portion of the map on display, and redraws it each time it is called, so applications using this overlay should call their MapView's invalidate() method after every zoom or scroll action.  It puts the grid latitude or longitude on each grid line, with longitudes displayed vertically.  The format in which these are displayed can be varied.  Supported formats are LLD (degrees and fractions, e.g. 52.03365°), LLDM (degrees, minutes and fractions of minutes, e.g. 004°13.255'W) or LLDMS (degrees, minutes, seconds and fractions of seconds, e.g. 52°13' 4.3").

To include grid lines on your MapView (represented here as mMapView), define a GridOverlay and add it the map's overlays, thus:

public void  drawGridLines()
{
        GridOverlay ol = new GridOverlay(
                     Color.GRAY, 
                      GridOverlay.LLDM,
                      mResourceProxy);

       ol.setStrokeWidth(1.0f);
        mMapView.getOverlays().add(ol);
}

Define a MapListener handler for the MapView, thus:

mMapView.setMapListener(new MapListener()
 {
         @Override
         public boolean  onZoom(ZoomEvent ev) 
          {
                updateMapPosition();
                mMapView.invalidate();

                return false;
         }

        @Override
        public boolean onScroll(ScrollEvent ev) 
        {
                updateMapPosition();
                mMapView.invalidate();

                return false;
        }
 });

(In my implementation, updateMapPosition() records the map's centre point and co-ordinates in the text boxes to the right hand side, as shown in the screen shots in my previous blog.)

There's been a somewhat prolonged hiaitus in this blog during the summer, not all caused by some extended sailing trips.  The olympics is partly to blame!  But I've gone back to the PC version of PCDB Waypoints, and finished the rather tedious task of preloading it with all the information I can find about lighthouses, buoys and beacons around the UK and near European coast.  That is now complete.  I can also take that information (from a Microsoft Access database) and load it into an empty PCDB Waypoints app running on my tablet.  Doable, but somewhat slow.  However, it means that I can really load-test the app on an enormous amount of data before releasing it into the wild.

There's a funny glitch in Androis whereby if I run a number of debug sessions of the same app on the same device, I get a number of identical icons in the Apps screen on the tablet, each corresponding to some terminal state of the app at the end of a debug session.  I've got roughly a screenfull.  I uninstalled PCDB Waypoints and reinstalled it to get rid of those, and then found some errors in the database import process which are now fixed.  So now I can get on with completing the functionality of this app and getting it ready to market.

Along the way, I've uploaded a new version of PCDB SuDuku Solver, at a reduced price.  The new version follows the evolving Android conventions for widget appearance which are designed principally to conserve battery power.  Next, I need to upload the same version of PCDB SuDoku Lite...

Also along the way, Samsung successfully upgraded my tablet from Android 3.2 to 4.0.  I've picked up the latest version of the Eclipse IDE and now need to explore the facilities of both new versions.

Recent work on PCDB Waypoints has concentrated on getting it to generate KML ("Keyhole Markup Language") files that can be read by Google Earth.  This is now reasonably successful, at least in the PC version.  I've used it to generate files of the various voyages I've been on over the last 60-odd years, some in my own boat, some on troop ships when my father was in the army after the Second World War, and others in cruises that Elaine and I have enjoyed over the last few years.  Getting it to work wasn't particulary easy, as the documentation is a bit difficult to follow, but I can now follow the routes of each of the voyages I've recorded.  I still need to complete the sework on the Icons used to show the type of waypoint; that's easy but tedious.

The Android version of PCDB Waypoints is coming on apace, but doesn't support this feature yet.  However, I can copy KML files generated on the PC onto my tablet, and with the help of a useful app called "KML to Earth", show a voyage on the tablet's version of Google Earth (I'm running version 7.0).  I won't be taking my PC to Northern Ireland, but the Irish routes are now fully planned out and I can display them all on Google Earth.

Now if I could overlay this data on my Android Navionics app...