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.

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.

More Progress

Added pencil mark functionality today, and the generator will pass a puzzle of whatever difficulty it generates to the activity.  The problem with the generator at this point is if we ask it for a puzzle of a certain difficulty, we have to put it in a loop until it gives us one with that difficulty, and what it does is it keeps generating and then coming back with "unknown" difficulty and continuously regenerates.  We decided to look at it and see if it was generating anything useful at all, and it was, so we put it out to the puzzle screen.  We will be doing some more reading on the generator and its difficulty ratings.  Other things we are looking at next are to gray out buttons when the digit count on the puzzle board reaches 9 and begin looking into the timer functionality.

Puzzle UI function so far

The puzzle UI is the one that has the most going on inside it - right now our functionality includes the following:

1. The board draws with all given numbers having a gray background and not editable, and the default selected cell when the puzzle first appears is the top left cell.
2. User can select a cell and the app will automatically (if setting is appropriate) highlight the following:
1. The row the cell is in.
2. The column the cell is in.
3. The 3x3 box the cell is in.
4. Any cells containing the same number, if the cell selected has a value (in a different color than numbers 1 - 3).
3. If a cell has a value in it and it is not a given cell, the eraser button functions properly and resets highlighting.
4. The button digit counts recalculate with every number entered/erased (and only appear if the setting is appropriate).
5. If a user tries to enter an invalid number in a cell (like a second "3" in a row/column/box), the puzzle will shake briefly and not enter the number.
6. Upon puzzle completion, the screen will bring up a dialog saying it is completed and it will redirect the user to the History UI (it will need to pass the score once the timer functionality is completed).
7. Screen orientation functions properly (no numbers are reset, etc).

Screenshot of new highlighting function:

The colors show up pale on the emulator, but nicely on the phone.

The next steps I'd like to look at in the immediate future is darkening buttons when there are 9 of the number present on the board (no more to place), pencil marks function, and starting to set up the timer.

Right now the puzzle is being generated by two hard-coded strings (one with the fully solved puzzle, and one with the blanks in the puzzle).  It will be replaced by the generator's puzzles (which will be looked at later today).

Stephanie

Solved problem with values persisting

Solved issue with the user-entered values clearing on orientation change - also set digit counts to re-calculate so they remain accurate also.

Puzzle UI Screens

I made the selection a little more defined (with an outlined box) and changed the background color of the given cells so it would be easier to tell which cells were givens and which were user-entered.  I had originally planned on using font color to do that, but there wasn't enough of a difference between the colors without it drowning out in the puzzle background, so I changed the givens to have a darker gray behind them  (however, if you select a blank, user-entered field, you can see the black box more, and it is darker blue than the highlights still as it was in the previous post).  For the sake of having an actual puzzle and testing user entry, I just got a generic easy puzzle from the Internet and put it in as a test puzzle.  The digit counts on the buttons are created dynamically and are only shown if the settings in the app request it.  Still no functionality with the eraser, pencil, or pause buttons, but the number buttons will enter on the screen.  That's the part that doesn't persist - user-entered numbers on the screen reset to blank because the puzzle object needs to be held over orientation to not be reset.  Also, if the user tries to enter an invalid number (one where the same number is present already in that row, column, or box), the puzzle shakes back and forth briefly.  I am also thinking about having the highlighting include (in a different color) any boxes with the same number in them (ie: if I select a box with an eight in it, all other eights on the board are highlighted as well).  Screenshots of the screens so far:

UI Screen Update

The UI screens are coming along nicely! Screenshots below (from IDE emulator)...

Splash Screen (similar appearance in landscape - fills width of screen)

Main Menu, appears after splash screen (similar appearance in landscape)

If you hit resume or new puzzle (choosing a difficulty from the dialog) you're brought to the puzzle activity;  each button is for a particular number, the small superscripts next to them are going to be where the "digit counts" are placed - right now they are just placeholder numbers, but later will represent how many blocks in the puzzle have that particular number in it (as this is also part of the settings, it will only appear if that setting is marked to show them)

Landscape view of the puzzle screen.  This was one of the more challenging to get to work properly, since I had to re-arrange all the buttons and things.

The history view (it has a scrollbar on the right side, but it fades out too quickly to catch it in a screenshot); it appears similar in landscape.  The help view also looks something like this, except with paragraphs of text rather than the list here.  When the app is finished we can write a specialized help section for the user.  Both text in history and in help is static for now, but history will be changed to a dynamic view of the user's times in the future.