TapTap - Delphi for Android 2013 contest review (in GooglePlay)

Posted by on in Blogs
TapTap - a winner of Delphi for Android 2013 contest. The project was a favorite at the beginning, as it represented a complete application, made with humor and the source codes were interesting to look at from the viewpoint of "design". The author - Nikolay Zverev - is a typical desktop-to-mobile developer, primerily mastering his enterprise-scale RDBMS-based application developer skills for years. Personally I liked the project the best as Delphi evangelist, while the other guys were in the contest jury.

TapTap sourcesready apk for TapTap (rus/eng GUI), exe buit for Win32.

TapTap app on GooglePlay

The author's description (rus): part 1, part 2, part 3, part 4, part 5 (with sources, direct link above)

How to submit the Delphi app to GooglePlay (rus).

Little interview with the winner to give more light to the project design, coding and components in use.

1. Nikolay, let me congratulate you with your win. Separate thanks for detailed description in your blog and shared source codes. Did you experience some difficulties when starting a new FM project?

Thanks :)

Yes, I did experience some difficulties, but more precisely say "non-VCL-logical behavior" from my viewpoint of desktop developer.

I really miss "Caption" property for TButton and TLabel ("Text" is also ok, but not so habitual). For me the properties Left and Top are joint in one property "position", while Width and Height are not combined (in something like "Size"). But FM is not VCL and tastes differ, of course.

I cant say my project is so complicated. Form-factor independency was my initial goal, so I designed my GUI. I had no mobile development experience, so did it my way :).

2. Could you please make a short review of your project for those, who have the same zero-experience (you don't already). Have you split GUI and logic into some different units?

The design is very simple: we have a main form, main and single, all the stuff is arranged in frames. Of course, many variants were possible, but I did my experiment. Frames are not linked somehow directly, they communicate via main form instance. The frames are:

  • Animated guy - some robot-Android, made from primitives in design-time and animation, triggered in runtime. The guy doesn't know what is he about and has not links to the code. He lives his own life.

  • Game area. The main logic is there, while it is only a pair of methods. The area consists of N-characters, fires their animation, checks the game is done.

  • Menu - set of buttons "Play", "Settings", "Help", "Credits". Any button fires the methods of the main form.

  • Panel with high scores.

  • Settings.

  • Intro/Titles.

3. Is this design the same for your desktop projects or did you invented this particular for mobile app?

My desktop Delphi projects are DBMS oriented, so have nothing similar with this mobile project. But if I start similar small game project with VCL, I'd use the same approach.

4. You used frames. We have new Delphi users, who start their projects with Delphi for the first time. Please, explain, why the use of frames is a good practice?

Of course, one can do applications in Delphi without frames. But with frames the development is simpler and more convenient.

In my project the frame for the guy (character) was absolutely effective. The other frames were not so necessary.

Let me explain, why frames are good. Everybody knows, that code duplication is a bad practice. You should isolate code in a special unit to prevent doubling. The same is true for design! You sit components on the form and form-design-text is automatically generated, and you should care about not-duplicating it. It's as bad, as code duplication. Use frames if you feel your design-"code" can be potentially duplicated. It happens when some parts of the design can be used in different part of the project.

Frames are pieces of GUI. You can first build up pieces of GUI as frames, and then use them as design-units to construct the complete picture. And it's easy to manipulate with frames (pieces), rather than all-on-the-form.

5. Possibly, many developers will want to start from reviewing you project as a good beginning. How should one start analyzing your project?

There are always two approaches. Frist, from general to details, and, second, from details to the general idea. In my blog I'm describing step-by-step from the details. So now I'm describing "in direct order".

  • Open drp-file. See Project Manager and open "View Source" from Popup menu (right click).
    Here one can see the declaration of the units in the project. The main form is there.

  • The main form - frMain. All starts happening from FormShow even, settings are loaded, Intro is fired (see fraHello frame). Then all the objects are created (CreateMenuAndDesk). OnResize event arrange the objects (orientation does play a role).

  • fraMenu - the menu, the main form methods are called.

  • fraScore - time is counted, the frame contains methods, that are called from outside. StartNewGame, StopGame, Pause/Resume. RegClick to record clicks, RegWin to fix the win.

  • fraOptions - as simple as that.

  • fraHelp - the same trivial things.

  • fraDesk - is the constructor of characters. It changes their states, fires the anmiations. FRobots is an array for the characters created, FRobotsToToggle are characters, who are in process of animated changing their states. FHelloRobot is a character, which "gestures hello".

  • fraDroid - is the character itself. Be careful, some "dirty" code is still there.

  • uNPC - is a "basic" frame, it keeps design-time sizes of the objects-frames and calculates ScaleFactor. Primarily it was constructed as a base frame for characters, then it fitted as a parent for all the frames in the project.

  • uAni - is my attempt to optimize animation technology. The idea is instead of creating N objects of TFloatAnimation, I create the only TFloatAnimation instance, which controls all the process by calling the necessary methods. The names of these methods start from PA prefix.

6. A beginner takes your project and wants to use it as a prototype for his/her own game, if you don't mind. What can be used and what should be re-make from scratch?

Of course, I don't mind. Otherwise I won't share the sources.

uAni, uNPC (I'd better name it uBaseFrame), fraDroid (derived from uNPC) are quite universal. I don't feel like advising, it depends. And my experience is not enough to give advices.

7. What do you plan as the development of the project?

I was thinking of adding more animations, sound, a pair of new characters (with Windows or Apple logos). More levels. But now the mission is accomplished, the app is quite playable. The game is small, the plot is simple. I don't think I can draw much attention by developing it further.

At the same time it's not some "odd job". This is my first game, my first serious experience in mobile development. It's really in my memory forever.

Preparing for Google Play

Final building the project

Future (by Seva):

I'm waiting for blog post on how the game runs on a new prize device (Nexus 4).

I'm waiting for short report (volunteer) on primary device Nikolay used to test his app.

I'll migrate the project on iOS, many contest guys did this successfully, as Delphi is a relly mobile cross-platfrom dev tool.


Check out more tips and tricks in this development video: