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.