Posted in Design, Programming

Tic tac toe

Ok, maybe this isn’t a great piece of art ( or code) but is that logic, you know, the one that is simple but you’re very proud of?
It was built with java and with free resources, except the  Elders of the Gillman Tribe of Atlantis ( the tie image) that was from talented and gifted graphic designer Bob Canada . You can download through this here (remember: you must download all .rar) and is available for all system with a JVM 🙂
and the source code is on my gitHub, just click here.

tictactoe - First view of game
First view of the game
tictactoe - during the game
during the game
tictactoe winner
winner
tictactoe - winner
winner
tictactoe - tied game
tied game

 

Posted in Programming

Blowing…

What if I want to blow? I’ve been thinking about it, why don’t we use more user interaction beside fingers and screen-orientation to archive a super user experience? so I though: what kind of different ways users can interact with … an app, a game, maybe? then I think about: why not blowing? it would be fun to make a game when the users needs to blowing to pass through a game phase, wouldn’t it?  Then I made it, but not graphics ( the graphics isn’t good at all) only the nice pure code in mind, available on my gitHub: the whole project, and the classe who does the detection with its code. Enjoyyy!

Posted in Programming

MVC… with Cocoa.Touch

You know (or don’t) that cocoa touch uses MVC (model, view, controller) to implement applications, beside the Delegate Design Pattern, but this one we’ll talk later.

Most of the Cocoa Touch classes fall into three categories: views kind, models kinds or controller kinds. And you’ll notice that views and controllers do the most of the hard work in your application.

Let’s first have a chat about Views. Views are responsible to all the user interaction objects. Buttons, scrolling lists, and everything else that appears in the iPhone screen are views. And if you pay attention, you’ll see that mostly of the already build views knows already how to interact with the users interactions. And you can always do a view yourself, off course, you’ll only need to extend your class to an existing view. It’s nice to know that mostly of built views extends to this standard classes: UIVIew and UIControl .

Models are, practically all that manage your application data. The models only know your data, but don’t have a clue about the user interactions and how to react to it. Think about it like this: thought about data, thought about models.

About Controllers, they are a bit complexes, comparing to views and models. They are the ones who transfers the information between models and views, if one model change its data, so the controller update the view, and if one view change its information the controller updates the data. The models and views don’t communicate directly because, if they did, you’d need a lot more objects. What if your client changes his mind and asks you another view to share the same data? Or worse, your boss? Think about controllers as a “task-setup”, whatever you must set, you should use the controllers.
You can read more about this subject on iPhone App Development: the missing manual by Craig Hockenberry or here, in apple documentations.

Posted in Programming

Have you ever thought about… Storyboard?

Have you ever thought about… Storyboard?

StoryBoard is a new tool available in the most recent versions of xCode  that allows the developer see graphically how will be the screen transition (where the screen is a scene) through some kind of funny arrow  ( the graphic representation of segue) .

It’s quite simple, very visual. But beware! The simpler things are what complicate the most!

What if you have such huge application with a lot of screens and functionalities?  Unless you have a huge screen, it’s going to be a bit tricky get track of every screen, mainly if you are in a hurry and have a tiny, invisible bug to correct.

Off course you can pass data through the segue with the method “prepareForSegue:sender:”, which is invoked on the view controller when a segue is trigged. This way, you can customize the next viewController before it appears on the screen.

You can programmatically force transitions with this method:  “performSegueWithIdentifier:sender:”, off course, on the viewController.

Take care when you are using scenes on iPad, it can handle multiples screens at once, it’s  not going to work  as you expect on iPhone. And with scenes, you can manage most of the behaviors through the dock, which display icons representing the top level objects of the scene  and, for me the most important, it can make action and outlets connection between scenes and ViewControllers.

 

Apple has a quite good documentation of the Storyboard and its components. Worth a lot get a moment and take a look :: https://developer.apple.com/library/ios/documentation/General/Conceptual/Devpedia-CocoaApp/Storyboard.html