jonathanrz

Hi

I have a little doubt, I spend data from Activity A to B with a bundle in the intent.

Where I should declare the keys? In Activity A or B?

Only to avoid confusion, I'm talking about the string that defines the data that will be set in the Bundle.Ex: public static final String KEY = "MyKey";

I declare always in the Activity A, but I think that if I could let all the keys in a file would be better, like keys.java or something like that.

Obviously, this is nothing that is generating errors, just a doubt about convention, a thing that I consider very important in software development.

jonbonazza

It should be a constant inside of the class that references it (In your case, Activity A).

alostpacket

Actually this is pretty subjective.

Jon's answer isn't wrong though -- it's just one way to do it.

Having a Keys file is OK too. Depending on the situation.

Another way would be to have an object that is passed between A and B as the place where the string is defined. In Android these are usually Bundles

There are a lot of strong opinions and years of advanced research about how to structure a program, but three things worth taking a look at are the concepts of cohesion, coupling and encapsulation.

Here's some more from Google on the subject too:
Android Application Framework FAQ | Android Developers

__________________
Apps: BlueMuze | Listables | PocketPermissions

Guide: Android permissions explained, security tips, and avoiding malware

t: @alostpacket w: http://alostpacket.com/

jonathanrz

Define a file to the keys will be better for cohesion and worst for encapsulation.

Do you think that exist a weight for each item?

jonbonazza

Like alostpacket mentioned, this is almost entirely subjective. My previous replied is a common (I don't really want to say standard, but...) approach as it provides a good balance of readability, maintainability, and compactness.

With that said, the "best" approach is whatever approach your designers and leaad developers tell you. If you are the only person working on the project, then in all honesty, it doesn't really matter. Just pick an approach that is most attractive to you.

alostpacket

^ exactly


Sorry if I confused the issue a bit there Jon's answer is a perfectly good one.

And (as he also says) if you are the only dev, then it's fine to put it wherever makes you feel comfortable.

I just wanted to expand on the answer a little bit and give you some tips on some things to read as you learn over time. No need to have perfect organization the first time you write something.

Coding is about learning concepts and best practices while managing your time, and getting your product finished.

So I just wanted to give you some ideas that you may want to read up on as you progress.




Also yes, you are correct in that sometimes coupling and cohesion can seem like opposites, but the goal is to make them work together.

I think a good easy way to help yourself organize things in the beginning is to ask yourself
These are the concepts behind the fancy words like cohesion, etc.

And most likely you will often find the "next" programmer to look at your code will be you, in 6 months or a year (when you have completely forgotten what the code does or how it works).

So it helps if you try and code in a way where you keep in mind the "next guy".

hth