I guess we're not the only people to be plagued by calls of this kind.  A few weeks ago we were getting a constant stream of them.  Asking the caller for his Microsoft payroll number seemed to make them hang up.  The upshot is that, if you're gullible enough to do what they ask, you put your computer and possibly home network at risk.

The WIndows Secrets newsletter recently ran an article on this, at http://windowssecrets.com/forums/showthread.php/141855-Hoax-calls-from-quot-Microsoft-quot.  I particularly liked the photo of one of the call centre staff responsible.
 
No posts for a few days as I've been too busy making substantial progess with PCDB Waypoints.  Since sortig ListViews and Fragments, I've now got tables and Activities working for Waypoints, Voyages, Routes, (Chart) Folios, Places, Boats and Icons (representing a Waypoint).  I'm currently revisiting the thornly problem of implementing a ComboBox widget in Android that allows autocompletion and still permits you to define a new item if the one you want isn't in the list.  Android has tended to forget this issue as all the examples of AutoCompleteTextViews they provide use a static list of strings such as countries, and thus adding a new entry doesn't do very much in Android (though I guess it may at the UN).

I want to base the drop-down list on a database table, allow autocompletion from the entries in the table, and provide code to add a new row to the table if what the user types isn't there.  I've made a start and now have a ComboBox class sort of working, in that it compiles OK and appears OK on the screen.  So far, though, it doesn't display the entries from the database and doesn't respond to the "Next" or "Done" keys.  More to do here yet.
 
After struggling with Fragments for three days, I finally sorted them on Friday.  The problem was that, in a two-fragment screen, the LH fragment that displayed a list of Waypoints, couldn't see the fragment in which to display the Waypoint details, so when I tried to display the details it fell over.  The solution, in the end, came down to the fact that I was expanding the details fragment in the wrong place - onActivityCreated rather than onCreate!

Once I'd fixed that, I've made some substantial progress.  The Waypoints facility is now working and enables me to store and update waypoints.  I've also implemented the Folios facilities, so that I can test the ability to refer to a Folio from a Waypoint.  The usual (for Microsoft Access) faciliy to define a new Folio from the Waypoint screen is now also working.

With those two facilities up and running, the next stage is to parameterise as much as possible so that the process of adding a new facility is as painless as it is with the Microsoft Access version.  That's tomorrow's task.
 
 
A reasonable person would think that, if Android supports two-item (or more) ListViews, and provides facilities to list a database query's results in a ListView, and enabled a user to select an entry this ListView, then it should be possible for an app to pick out the values of individual items from an entry.  Typically, one of the items would be the record's ID and you need this to update the record later.  I'm sure it's possible.  But I've just spent most of the day trying to find out how to do it, to no effect.

Another frustration was in trying to use a two-fragment layout where the left hand side is a list of records and the right-hand side is the details associated with a selected record.  Again, little joy.  There are various examples and tutorials on this in the Androidsphere, but I still can't get it to display the "details" fragment without generating a runtime exception.

Hopefully, better progress tomorrow.
 
In between digging into the more obscure aspects of Android, life goes on.  We have a visit today by daughter Georgina and son-in-law Richard with new baby Emily.  And last night was the first rehearsal of the Beaumaris Singers for this term.  We have a concert, called "Jubilate", at the end of May including a number of coronation anthems.  Naturally "Zadok the Priest" will be there, but so are some much less well-known numbers including a Walton piece "Jubilate Deo" in multiple time signatures, and a lovely Byrd anthem "O Lord, make thy servant Elizabeth our Queen".  I'm looking forward to it.  We'll be doing some of the same pieces at Cosford air base in June to celebrate Veterans Day.
 
I was having a drink with a couple of old colleagues the other day, and one said, of Android "it's amazing the number of things you can do with it".  True.  But its very scale makes it almost impossible to find out succinctly how to do anything.  There are copious amounts of material on the Android Developer website, almost all of which stop short when you're looking to link to something complex rather than just develop a superficial version of the subject under discussion.  Thank goodness, then, for the www.vogella.de website that does show how to develop quite complex and complete apps in a well-structured way.  I used it to sort out some issues with SQLite, which I plan to use when porting PCDB Waypoints to Android.

The first thing I need to do with SQLite, though, is packaage it up into a number of reusable functions.  PCDB Waypoints uses a large number of screens and tables, with similar processes available on each, and a large number of links between tables, for example Voyages to Routes, Routes to Wayoints and Locations, Waypoints to Marks,Icons and Charts, Charts to NMs Notices to Mariners), and many, many more.  The last thing I need is to have to implement each of these to the excrutiating level of detail given in the Android tutorials I've read.,

There are other obstacles to overcome.  Fragments, for example, are sold as similar to Activities but when I try to display a Waypoint's properties in a Fragment, things that compile properly in an Activity won't compile in a Fragment for no obvious reason.

I suspect that porting PCDB Waypoints isn't going to be a trivial
 
 
Home again.  Caledonia is safely launched, still afloat on her mooring, and that mooring was picked up at the first attempt in a gentle NW breeze.  I've sometimes had a pattern full of squiggly circles, like a child's drawing, on my chartplotter showing several failed attempts to pick up a mooring, but this one went without a hitch.  Just a single loop to line up into the wind, and then straight to the buoy.

First Mate Elaine was in Lincoln viisiting an aunt, so it fell to Leading Seadog Monty to help with the launch, which he did very ably, largely by keeping well out of my way.  And he hasn't yet taken a chunk out of the new sprayhood.

So back to SuDoku Solver.  Now that both the Full and Lite versions are available on Google Play, I'm looking at enhancements, particularly feedback from users including our son-in-law.  So the OK button will be enlarged and put on a separate line, and a "+" button will be added in its original place to enable you to reinstate Candidates you've already deleted.

Son-in-law also thought it should be more colourful, but colour on a tablet device equates to greater battery drain, and is severely deprecated by the Android tzars.  I will look at the option of displaying Killer SuDoku groups in different colours, rather than using the dotted lines that enclose them at present.  The principal objection to this, it seems, is finding a way to marry it up to the current app facility which uses colours to identify all the Cells that contain a particular digit as a Candidate.
 
One of the key features of PCDB SuDoku Solver, when used to solve a SuDoku game in particular, is the use of the number pad buttons to highlight all the Cells that contain a particular Candidate value.  It's amazing how quickly this feature can enable you to solve even Super Fiendish games.

I've implemented this by setting the button's background colour to the highlight colour of the digit, and then when you select another number pad button, reset the background to DarkRed.

For the next  versions of both SuDoku Solver and SuDoku Lite, I want to move more towards using the full features of the Holo Dark theme which Android pushes as a key part of the "Android experience".  Using attractive shades of darker or lighter gray, with a black background, this is designed expressly for mobile devices to help save on their use of battery power.  I've used many features of Holo Dark in the released versions, and the major hangouts so far are the use of colours on the grid, which I intend to keep, and the dark red shade and lack of rounded corners in the screen buttons.  So I've spent the last day or so working out how to exploit Holo Dark buttons while still being able to set the button background colour to that of the selected candidate digit when one is selected (which is easy) and then set it back to the default when a different digit is chosen.  This latter has proven surprisingly difficult, and in the end the only way I found to solve it was to import the standard Android button backgrounds for the various states of a button (normal, pressed, focused, disabled) and set up an XML file that specifically displays the correct background image as the state changes.  Then, when a number button is deselected, it is necessary to reload that XML file as the button's backround resource.  [I can assure you this all makes sense to an Android developer!]

That is now working in both products.  A further consequence of the change to using the full Holo Dark feature set, however, is that the buttons are slightly smaller than they were before, as Holo Dark insists on a greater gap betwen buttons than I had been using.  Quite reasonably, too.

I now have two users of the Lite version, and no error reports yet.  Both are using different tablet device types, so any feedback will be truly useful.  There's only so much you can do with the Android emulator.

At that point, I need to head off to Holyhead tomorrow mid-day to get ready for the launch of my boat on Wednesday.  So far the forecast is looking reasonable.  The wind will be trying to push me onto the cliff face just to port at I come out of the crane backwards, but probably not strongly enough to cause any difficulties.  And I've already run the engine since changing all the filters, so there shouldn't be any problems there.  (It's a bit embarrassing when the engine doesn't start after a launch.  Been there, done that, didn't bother getting the T-shirt.)  The last remaining problem will be picking up my mooring single-handed.  Oh, and keeping the dog out of mischief.