Another Update

Everything seems to be working well so far, this week functionality for digit-first entry and writing/formatting the help section of the app is completed.  Everything's going as expected and work will continue on the loader dialog and will begin on the user guide and installation guide next week.

Pausing / Resuming

So far, so good.  It saves puzzle information (difficulty, hint flag, time, and puzzle) directly into a persistent file on internal android storage (same as the way the history does).  When the puzzle is resumed, the file gets deleted (this way it is not resumed multiple times).  The resume button on the main menu checks whether or not the file exists, and enables/disables the button accordingly.  The timer transfers very easily and accurately.  Pencil marks also transfer properly.

On an unrelated note, I also changed the cap on how many scores the history saves for each category from 10 to 25.

Puzzle dificulty issue has been fixed

The puzzle difficulty issue has been resolved. Puzzles are now being generated at the requested difficulty. As per my previous post, the issue was with the record history flag not being set properly.

This has increased the load time for puzzle generation. A loading screen will be created for the transition.

Another Timer update

I figured out the sorting problem when times are passed to the History activity, so now that's working just fine (including passing the hints used flag).

Now, the actual timer itself..... Android apps are paused when the screen shuts off, and resumed when the screen turns back on.  However, this isn't necessarily when the user unlocks the screen.  If the person doesn't click out of the app before locking the phone, it will pause properly but it will resume the application (and therefore the timer) when the screen turns back on, not when it's unlocked.  People who don't use a lock screen won't see an issue at all, but if you leave the screen on and locked for any length of time, the timer will definitely reflect this.

I started fixing this using a broadcast receiver that gets a signal from the intent when the screen is unlocked.  It works for the most part, but not in a situation like this:  lock the screen, and say you turn the screen on to check the time or something but you don't unlock the phone, and then just turn it back off.  When you DO unlock your phone and look at the app, it shows that the timer has been counting up, and I'm not really sure why it does this or how to fix it yet, or if I can using the broadcast receiver object.  I have to look into it some more and find a better solution.

Generator difficulty issue

Determined why the generator is not providing difficulty. Generator is not providing a difficulty because the arraylist solveInstructions is not being incremented. Further investigation needed to determine why solveInstructions is not being incremented.

Possible cause record history flags not reset.

Also noticed that in our code the when solveInstructions.clear(); is called, it is not incrementing the modCount either. Further investigation needed to determine why modCount is not being incremented.

Timer Update

So, I ended up using a chronometer for the timer, and so far, so good - it automatically counts without any complicated handlers or services exactly the way I wanted it to, and the text can be easily passed right into the history activity.  I did get it to persist on an orientation change (it would restart otherwise), but now it needs to persist (accurately) through screen lock and through the app being put in the background (like if the user hits the home button and does something else before returning to the app).  Right now it persists orientation change the same way the puzzle does - within the puzzleView.  Unfortunately, I think it might have to be moved into the activity instead for the other persistence issues, but that will come.

I also did a little UI change on the landscape orientation of the puzzle view.  I moved the difficulty and timer over above the buttons and allowed the puzzle grid itself to take up more space which makes it that much bigger in that view.  (It was a bit small before).  The grid is always square and measures itself by the smaller dimension (width or height) and draws according to that since it's different for portrait and landscape views.

So, before:

Before

And after (with the timer):

After

Now the big issue is expanding the timer persistence and tying in the completion times into a sorted list with difficulty to feed into the history.

Also fixed today was the puzzle generation in the activity's onCreate - activities run this method multiple times, so it was generating unnecessary puzzles when the orientation changed and other times it didn't need to be.  I moved where the puzzle was generating so it doesn't do that, and the orientation changes process much faster than it was.  The issue now is that it seems like it hangs when the puzzle is generated, so eventually a load spinner or some sort of loading item will be put in, but that isn't as high a priority as the rest of the timer.

Google Code URL

I don't remember if we provided this URL at the start, but this is the link to our Google Code Project where our code is hosted using Subversion version control.
(http://code.google.com/p/tbsc-senproj2013/)

More Updates

Fixed a problem with undoing a move (the pencil marks in the cell were not being restored properly) and a back-button navigation issue occurring after a user completed a puzzle and went to the History screen (it would go back to the still-editable puzzle); we also have the menu functionality done for undo, hint, validate, reset, and solve.  Selecting solve will replace all number keys at the bottom with an "OK" button that will bring them to the History screen and not record their score.  Score functionality is still waiting on implementing the timer.  I looked at some of that and may use a chronometer (an Android object) or a Handler of some sort to get the timer at the top to continue updating.  I'm also looking into the pause and resume functions - I think what I might do is make the pause return the user to the menu screen and they have to hit resume to keep working on the puzzle.  It should also do that when the user doesn't return to the puzzle before the app is closed by the system (can probably be done in an onStop or onDestroy method, I have to do more reading on the activity lifecycle).  I also need to figure out how I'm going to store it.  I was originally going to use an xml file or some sort of saved file, but I think there may be a more efficient way that doesn't require creating an external file.  More to research, anyway.