Project-oriented programming on Android

I'm fooling myself with basic Android programming with Eclipse. I am currently browsing a book and playing with some sample code that is written in a book.

I noticed that in this particular book all the examples still follow the path to Main-Activity. I don’t think this is a very good object-oriented programming practice, since I'm from a traditional Java background.

Is this common practice for mobile platforms? Shouldn't all classes be contained in their own files?

+7
source share
3 answers

Shouldn't all classes be contained in their own files?

Not necessarily, as Android Activity is a "special case" class. If you have not already done so, I would recommend that you read the Application Basics and, in particular, the "Actions" section in the Application Components section ...

Activity is a single screen with a user interface. For example, an email application may have one action that displays a list of new emails, another action for composing an email, and another action for reading emails. While actions work together to form a cohesive user interface in an email application, each is independent of the others. Thus, another application may trigger any of these actions (if the email application allows it). For example, a camera application may start working in an email application that composes new mail so that a user can share an image.

Pay attention to the section of text in bold. The fact is that the Activity itself is not a complete application, and if it is allowed, any third-party application can potentially call Activity in one of your applications. Thus, as a rule, make Activity as self-sufficient as possible. One specific example is the use of something like AsyncTask , which provides methods for executing a background thread, as well as for managing the user interface - nesting a private class that extends AsyncTask is quite common and simplifies the code. For the same reason, attachment classes that extend BroadcastReceiver are common.

However, there is nothing wrong with using separate Java class files for POJO helper classes, for example, it just comes down to how complex your application is, but it can mean special attention to how certain Android classes work - t24> class, in particular, if it is defined in a separate class file, try it and you will understand what I mean. :-)

+6
source

OO is the introduction of functionality to classes. How you write these classes determines whether it is good OO or not (although this is debatable). Regardless of whether all classes in one or more files or each class has its own file, this is a matter of taste and is not directly an OO problem.

Since this is a book with small samples (I think), it can be read as easily as all classes in separate files.

+5
source

If you use the right OOP, you can create template-based applications much faster and more efficiently.

You should do this, for example, if you have a common database application and you can use multiple databases with minor changes.

0
source

All Articles