Loading Dialog Implemented

We finally got the loading dialog to work properly using a Handler and a separate background thread.  We also uncovered an issue with all dialogs we had in general on orientation change, and were able to handle it accordingly (they needed to be officially dismissed upon Activity onStop so it wouldn't cause window leaks).   Screenshot of progress dialog:

This week we will be continuing work on the User Guide, Installation Guide, and code commenting.

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.

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:

Potential generator found

A potential generator has been found from http://ostermiller.org/qqwing/. The following features are listed on the website:

• Fast. It can solve 1000 puzzles in 1 second and generate 1000 puzzles in 25 seconds.
• Uses logic. Uses as many solve techniques as possible when solving puzzles rather than guessing.
• Rates puzzles. Most generators don't give an indication of the difficulty of a Sudoku puzzle. QQwing does.
• Can print solve instructions. Tells steps that need to be taken to solve any puzzle.
• Customizable output style. Including a CSV style that is easy to import into a database.

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.

Basic Test App

Well, today I finally finished the basic development tutorial I was working on (from the Android IDE's website - it's for building a basic app and passing information to new views/screens).  I finally got it to work, so I figured it was post-worthy.  I made a very basic UI with buttons that just go to a separate view (so I know it worked).  It ran in the emulator AND on the real device.  The nice thing that I just found out about is that the IDE will talk to the phone if it's plugged in (with developer USB debugging allowed) and will run the app on the phone right from Eclipse (which is extremely convenient).   Now for the real thing once the design document is finished!!

--Stephanie