The grid is a means of viewing contents, not of storing the representation. Ultimately, your grid is made of cells which have contents and therefor your underlying model object is perhaps best embodied by the cell. There are a number of ways to design the underlying storage for a Sudoku game and the bigger challenge will certainly lie in the generation of puzzles. However, the advice to take from this is to not determine your model based on how it appears on screen - the view layer is totally separate and so doing something like storing the board a a two-dimensional array would be a bad idea.
You can do this with either UIViews or CALayers as subviews of the main superview. You'll need at least 81 of them (one for each number in the Sudoku grid). Layers are lighter weight and less resource intensive, but views have a little more functionality. Which you choose depends on what you're trying to do.
There was an article somewhere about how to implement a Sudoku solver. I think that it used a data structure like this:
- a grid has 81 cells
- a cell has three group memberships: one column, one row, and one box
- a group has 9 cells (references)
A cell has some more properties, depending on what you want to do with the structure:
- a value
- a
hidden
flag (for a game) - a set of possible values (for a solver)
For such a completely uniform grid, I would create a subclass of UIView
and have it determine which row and column the user has touched using a simple calculation:
int touchedRow = 9 * touch.x / [self bounds].width; int touchedCol = 9 * touch.y / [self bounds].width;
I don't see much benefit in creating 81 individual objects in memory, when one object would suffice.
I've fooled around with a Sudoku game before and I did the gridlines and number drawing in a single view. Not because of memory constraints (using a single control and a reusable cell memory shouldn't be much of a concern) but because it only takes some simple math to figure out the locations of the grid and numbers, and programming a view is going to be easier at first. If later on down the road you start to feel overwhelmed with the amount of drawing and event handling code in your view class, you might want to make a reusable cell object that does much of the work, similar to UITableView.
Core animation would certainly work here too, if you need animation or not. A Sudoku board probably wouldn't have much animation, but if you do (maybe a sliding 'selection' box?) this might be the better choice.
Hi.... I can't get the idea how yo create such a grid.... i need to build an interactive grid, with such, 9 X 9, 15 X 15, or n X n dimension.... could anyone lemme know how to do this..!
Do i need to use OpenGL for this or it's okay to form a grid without OpenGL..? I also need to put zooming with animation on the rectangle selection or selection of any crossing points of rectangle..!
Can i have some coding details? I'm a newbie..!
Please if anyone have answer for this..! I thought to have n X n objects on my UIView but it slows down the app extremely.
Thank You.