It seems to me that passing extras via Intent calls is a violation of encapsulation, since classes are directly communicating with one another. That being said, the only viable alternative to this that I have found is setting a variable in some shared class and just having each activity pull data from it - part of me, however, can't help feeling that this isn't a great design choice either. Can someone shed some light on this?
Encapsulation, as one of the whale of Object-Oriented paradigm, assumes that you free programmers, who will use your class in future, from the necessity to know how does your component built inside and what complex aspects does it hold, carrying out this information to comfortable and clear programming interface (in the best cases).
Intent model was developed so, that it assumes interaction between main components of operating system, especially Activitys, and also it assumes that you need to accompany your intents with some concrete information such as kind of ACTIONs you want to perform, a CATEGORY of your intent and some set of DATA that need to implement your intents. So this is convenient model in such kind of interactions.
At the same time, using some shared class between activities when there is a ready solution for that, is rather irrelevant approach, IMO.
It isn't, you'll end up needing it. Usually I pass minimum info between activities and then check out big data in the launched activity's onCreate().
Related
So, i have MainActivity. It has a large number of methods that relate to different aspects of the application. For example, I have 5 methods related to the implementation of the calendar (methods like getCalendarView(), setCalendarSettings(), etc.), which occupy a large place in the code. Should I put the calendar methods in a separate class, and in the MainActivitiy code just call these methods? Would it be considered good practice or leave it as it is?
First, don't put any business logic inside your Activity. Your Activity is your View and has to handle the user interactions and update the UI based on the responses from your Data Source. In other words, you have to separate and group your code in layers which to communicate each other and every one of them has to has specific job.
Best practice in Android is to use some an architecture pattern like Clear Architecture, MVP or MVVM, I recommend MVVM.
You can start from here:
https://developer.android.com/jetpack/docs/guide
and continue with this:
https://medium.com/upday-devs/android-architecture-patterns-part-3-model-view-viewmodel-e7eeee76b73b
You also can check some examples here: https://github.com/android/architecture-samples
I wondered if it makes sense to make a class that inherits from the Intent class and that overloads the putExtra method, allowing to pass custom objects, instead of using Parcelable.
Is it something sensible? Is it much slower than passing parcels?
I would like the process to be extremely fast, keeping the object in memory, and from what I understand, parcels use serialization instead.
It's an interesting question. Intent is a universal data wrapper that, among it's other functions, allows you to transfer data between processes, that's why you need your data in parcelable form.
In fact the intent itself is parcelable, and to implement a proper subclass you'll need to parcel all your added fields and you'll basically end with the same intent class, just with a few exposed fields.
Here is a subclass of Intent for reference: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.0.1_r1/android/content/pm/LabeledIntent.java
So I would not recommend you to follow this approach. If you want an alternative way of sending data between different components I would recommend you to use concept of EventBus and create something like https://lorentzos.com/rxjava-as-event-bus-the-right-way-10a36bdd49ba
Lately I've read this comment on Reddit:
I think EventBus on android is popular because people don't know how to share a java object reference between android components like a Fragment and an Activity, or 2 Activities and so on. So basically I think people don't know how 2 Activites can observe the same object for data changes which I think comes from the fact that we still don't know how to architect our apps properly.
As far as I know:
directly reference values
((HostActivity)getActivity()).someValue
may cause problem such as memory leaks or NullPointerException
Callbacks or other observer pattern
EventBus,inner class like listener and etc
So I was curious that whether there is any other ways , could you share with me on it?
imo, there are few ways out of your opinion such as:
use local db, now ORM like Realm is really popular, its also safe way.
use share preferences if your object is able to convert to json, its up to your situation.
use intent with serialize/parcelable object bundle.
use a singleton, now #scope with Dagger 2 is good choice.
use RxJava as event bus.
This is a bit of a general question, but I will give a specific example for you.
I have a bunch of activities in an App. In all of the activities, there is a Facebook button. When you click the button it takes you to a specific Facebook page. I wish for the button to behave exactly the same way on every page.
Right now, in every single Activity, I create an onClickListener() for the Facebook button and make the intent and start the activity. It's the same code in every single Activity.
What is the best way to write this code once and include it in multiple activities? Is there anyway to include other .java files?
One solution that I know would work, is to make a base CustomActivity class that extends Activity and then have all activities extend CustomActivity. Then put my onClickListener() code in CustomActivity. I'm new to Java though and I wasn't sure if that was the best approach or not. Some of my Activities already extend other custom activity classes as is, so extending things that extend more things might get kinda messy, I dunno.
UPDATE
Playing the devil's advocate here: Lets say I went with the inheritance route and I create some CustomActivity that I want my Activities to extend. CustomActivity would contain a bunch of general code that I need to use for all Activities, including but not limited to the Facebook button functionality. What happens when there is an Activity that I need to use generic code from the CustomActivity but there is no Facebook button in that specific Activity?
A common base class is perhaps the best approach. (It doesn't work quite so well if some of your activities extend Activity and some extend Activity subclasses (such as ListActivity).
An alternate approach is to create a separate class that implements the logic of your click listener. This doesn't eliminate all duplicate code — each activity still needs to instantiate and register a listener — but the logic for what to do will only need to be written once in the listener class.
In either alternative, you might consider assigning the android:onClick attribute to the button. That way you don't need to register a click listener; you just need to implement the target method in each activity. This is particularly useful with the base class approach.
UPDATE
Suppose you go the inheritance route and you want an activity with no Facebook button. If you are using the android:onClick technique, then you don't have to do anything different in your code — since no button will invoke your onClick method, the method will just sit there doing nothing. If you are installing an OnClickListener in code, then you just need to test that the button exists (i.e., that findViewById() did not return null) before registering the listener.
Generally a common base class is NOT the best approach (although it's certainly valid).
This took me (and every OO programmer who "gets" OO that I know of) a while to really grok, but you should use inheritance as sparingly as you possibly can. Every time you do it you should ask yourself if there is REALLY no other way to do this.
One way to find out is to be very strict with the "is-a" test--if you call your base activity a "Facebook Activity", could you really say that each child "is" a Facebook activity? Probably not. Also if you decided to add in Twitter to some of the pages (but not others), how do you do this?
Not that inheritance is completely out! A great solution might be to extend a control to launch your facebook activity and call it a facebook button--have it encapsulate all the stuff you need to do to connect to facebook. Now you can add this to any page you want by simply dragging it on (I'm pretty sure android tools let you add new components to the pallet). It's not "Free" like extending your activity class, but in the long run it will cost you a lot less stress.
You probably won't believe me now, we all need to learn from our own experience, just keep this in mind and use it to evaluate your code as you evolve it over time.
--edit, comment response--
You can encapsulate any facebook activity you think you will use a lot in it's own class--get it to a bare minimum so you can just add it to any class in a one-liner.
At some point, however, you may decide that it's STILL too much boilerplate, I totally understand. At that point you COULD use an abstract base activity like you suggest, but I wouldn't hard-code it to handle facebook explicitly, instead I'd have it support behaviors such as facebook (and maybe others), and turn-on these behaviors as desired. You could then tell it NOT to add the facebook behavior to a given screen if you like, or add in Twitter to some of them.
You can make this boilerplate minimum, for instance if you want "Standard" functionality, you shouldn't have to do anything special, if you wish to disable facebook you might start your constructor with:
super(DISABLE_FACEBOOK_BEHAVIOR);
and if you want one that also enables Twitter you could use:
super(DISABLE_FACEBOOK_BEHAVIOR, ENABLE_TWITTER_BEHAVIOR);
with a constructor like AbstractAction(BehaviorEnum... behaviors).
This is more flexible and you actually can say that each if your activities IS-A "behavior supporting activity" with a clear conscience.
It is, of course, a perfectly good approach to be less flexible at first and refactor into a pattern like this later when you need to, just be on the look-out for your inheritance model causing problems so you don't let it mess you up for too long before you fix it.
Well, extending things is the principle of OOP, so I don't think this is a problem to have more than one level of subclasses. The solution you thought about is in my opinion the best.
Absolutely. Use inheritance to gain some reusability as you should with OOP. You'll find, as you progress, that there are gonna be more and more things you'd like to reuse in your activities -- things more complex than an onClickListener for a FB button -- so it's a great idea to start building a nice, reusable "super" activity that you can inherit from.
I am fooling around with some basic programming in Android using Eclipse. I'm currently looking through a book and playing with some sample code that is written in the book.
I have noticed that in this particular book, all of the examples so far take pace in Main-Activity. I don't believe this to be very good Object Oriented programming practice as I am from a traditional Java background.
Is this the common practice for mobile platforms? Shouldn't classes all be contained in their own files?
Shouldn't classes all be contained in their own files?
Not necessarily as an Android Activity is a 'special case' class. If you haven't done already, I'd recommend you read Application Fundamentals and in particular the section on 'Activities' under Application components...
An activity represents a single screen with a user interface. For example, an email application might have one activity that shows a list of new emails, another activity to compose an email, and another activity for reading emails. Although the activities work together to form a cohesive user experience in the email application, each one is independent of the others. As such, a different application can start any one of these activities (if the email application allows it). For example, a camera application can start the activity in the email application that composes new mail, in order for the user to share a picture.
Note the section of text that I've highlighted in bold. The point is that an Activity in itself is not the complete app and if allowed, any third-party app can potentially invoke an Activity in one of your apps. As such, it is common to make an Activity as self-contained as possible. One particular example is the use of something like an AsyncTask which provides methods to execute a background thread as well as manipulate the UI - nesting a private class which extends AsyncTask is quite common and simplifies code. Nesting classes which extend BroadcastReceiver is also common for the same reason.
That said, there is nothing wrong with using separate Java class files for POJO helper classes, for example, it just comes down to how complex your app is but it can mean taking special consideration of how certain Android classes work - the AsyncTask class being one in particular if defined in a separate class file, try it and you'll see what I mean. :-)
OO is about putting functionality in classes. The way you write those classes defines if it is good OO or not (although this is debatable). Whether all these classes are in a single or a few files, or each class has its own file, is a matter of taste and is not directly an OO issue.
Since this is a book with (I think) small samples, it may be just as easy to read the way it is, than when all classes are in separate files.
If you use proper OOP you can create Template based apps much more quickly & efficiently.
You should strive to do this for example if you have a generic database app and multiple databases can be used with minor changes.