I'm finishing an application, the thing is that I have a couple of layouts and all the code concentrated in an Activity.
I have 5000 lines of codes and when I have to fix something is a pain in the ass to find what im looking for.
as im really new in Android development, I can't find a way to split the code into several classes.
is there a simply way of split one layout with one activity?
its really annoying to declare each layout with his corresponding activity in the manifest.
thanks for any suggestion.
Actually it is not Android. But OOP (Object Oriented Programming) concept.
Of course you can split function in one Activity into several classes. For example, if you have AsyncTask you could make it outside an Activity, if you have Adapter that reads from DB you could also make it outside an Activity. Just call to those classes when needed. And any other general functions you could also make it outside an Activity perhaps in Utility class or something.
From what I understand, you have multiple layouts for a single Activity? You could check out the Fragments API and divide up the Activity into easily manageable Fragments. As for the 5,000 lines of code, try to divide that up into separate classes with static access or is there a way you could use data objects? You really shouldn't have 5,000 lines of code in ONE class, divide that up into separate classes.
Well, the Android way is to use activities to hold your layouts; that is what they are intended to be used for. It would be a good idea to make your program as object oriented as possible... Here's why..
Java is an object oriented programming language.
Help make your code easier for you to understand, follow, and make changes to.
To make your code easy for OTHERS to follow.
Ensure cohesiveness in your application.
So it would be a good idea to make your application as functionally cohesive as possible. It will save you much trouble in the future.
Related
I've been reading about the include tag on xml, fragments to use on layout for smartphone and tablets but I'm getting more confused than getting a solution to my problem.
My App has 4 screens.
1 - You login and it download info from a json
2,3,4 - From login, Activity 2 load (A list with custom adapter), where you can click one of 2 images to jump to 3rd and 4th activity.
I need now to create the activity 1, 2, and 3 again with different JSONs being parsed, with 1 and 2 having the same layout of the existent ones and 3 with a different layout.
The code I need for them to work is(or can be) the same (Download Task with AsyncTask, button click listeners, etc) I already have for those activities.
I think it's not a goot pratice to copy basically the same getView method, for example, and paste on a new class, right? The buttons wouldn't work on the second range of screens for example.
So, what approach should I take that isn't copy and paste code and change things manually?
Sorry for the newbie question.
If needed I can provide code.
PS 1: I've already did tests with include on xml and copy code but that doesnt look professional
PS 2: Is fragments only for different screens like tablet or I could make something with it?
That's several questions, so here's several answers, including to some un-asked questions:
To the greatest extent possible, strive to remove as much code as possible from your Activities, Fragments, etc. If it doesn't have anything to do with the Android lifecycle or actually putting something on the screen (e.g. parsing JSON), put it in a "plain old java" class. Also, this way, you can share the functionality among Activities.
IMHO, you should never use an AsyncTask, for any reason. They're used with an Activity or Fragment, but don't respect the Fragment or Activity lifecycle, so are often the cause of crashes that can be difficult to diagnose. Use something synchronized with the lifecycle, like a Loader. Or go the RxJava route, where Subscribers can be canceled at the appropriate point in the Activity/Fragment lifecycle.
Fragments can be good for code re-use, but they have a slightly different lifecycle from Activities, so they can be difficult to work with, so use them sparingly and be careful. If you're doing it just to re-use a bit of UI (but not behavior), a layout "include" is probably better. For behavior, a custom View class can be a good alternative to a Fragment.
Don't do HTTP / REST access yourself, using primitives like HTTPUrlConnection. There are a lot of corner cases that are going to get you into trouble. Use one of the several really good open-source libraries that are built for this purpose. I highly recommend Retrofit.
My app has a creation page and an edit page. These two pages are almost exactly identical, save the difference you can't edit without first creating the page. It's working perfectly fine, except it seems a little redundant have two separate activities with the same actions.
My question is, what is the standard/best approach to this situation. Should I create a new class, from which both these classes could access methods from or could it be one activity? Also, there is some amount of calculations, (a small series of random number generators) being carried out, should this be running on a separate thread? Or is it fine running on the main thread?
An example of what I have is kind of like android contacts app, you can create new contact and you can also edit that contact, which is essentially the the create new contact page.
Approach 1:
Have a Base Activity that extends Activity.
Then add all the common code like inflation of layout, some logic, life cycle handling etc.
Then create 2 classes like CreatePage and EditPage. These two new classes will extend the Base Activity.
Just handle the little variations in xml page dynamically here at runtime. Maybe in onStart().
This approach show cases basic OOPS of 1 parent Activity and multiple children.
Approach 2:
Have a Base Activity, and put create page and edit page as Fragments.
Just replace the fragments on your activity according to your program flow.
P. S. My answer may be a little abstract since your question is generic :)
I am very in doubt of the structuring of my application. When to use Fragments is a big question for me still. I understand the concept of fragment, but I would like to know how more experienced programmers use them. Is it really only when there is a specific task the fragment should do?
For instance, POP-UPs, what layout would be better used?
And back to the fragments, do you usually have a skelleton fragment that can be used for more than one thing, and then reshape it to different final forms (minor changes) or would you just use different fragments if the layout changes?
You should use fragments in a few situations but its going to depend on your app really.
If you have a layout that is going to be used in multiple places and the code is relatively the same, that is a very good candidate for a fragment so you can keep code down.
If you are making an app where the layout changes based on orientation or device type (tablet vs phone) then fragments are highly recommended to hold different layouts. It makes it easier to change or show multiple layouts if need be on a tablet.
I'm sure there are more scenarios but I would say these are the basics for fragment decision
The most common way I use them is as a kind of plugin layout for my activities. Let's say I have several activities and all of them need to display an address, phone number and some buttons (call number, launch navigation/gps, etc). I pass the fragment the id and the fragment does the legwork of grabbing the information and populating fields for my activities. This way, if I need to add anything, say an email address, I just need to modify one section of code rather than each activity and layout file.
OK, I get the concept of Fragments being modular/ interchangeable "sub-activities" but given that fragments have their own lifecycle much like the one of an activity and can pretty much do anything that an activity can, from a best-practice standpoint, does that mean we are to start coding a single activity for the whole app (say, the main_activity) and simply adding/ replacing/ removing fragments within that single activity?
If not, then how do I know when it's time to create a new activity instead of continuing to push new fragments into the same old activity?
Just trying to understand how to best organize my app's features into activities and frags. A practical example would help (no code necessary, just the concepts).
Cheers,
No, I does not mean that you should use single activity.
Fragments are to help you organize ui elements (especially on big screens (like tablets)).
They also introduce new layer of reusability (using fragments for loaders, simple views) across your projects.
I recomend you check Google NewsReader SDK example which is a great way to see how to implement activity/fragment patterns depending on what type of screen it is launched on
http://developer.android.com/training/multiscreen/adaptui.html
Download sample button is on the right
No fragments are just one way to reuse parts of an application. For instance you can use a fragment in several activities. On the other hand you can of course have several activities that use different fragments or do not use fragments at all.
So summary: no you don't need to. Fragments are helpful, if you build up multiple activities that use a similar or equal component as a part of their layout.
With so many ways of implementing an OnClickListener within Android, I'm wondering whether there's a best practice or a more recommended way of doing it over the others (ie: I remember reading certain ways require more memory than others)?
At the moment I know of four ways to implement the OnClickListener, these are:
Make your Activity implement an OnClickListener interface.
Inner Class OnClickListener.
Inline Class OnClickListener.
Use android:onClick attribute in XML definition of a Button.
Out of the four options I'm leaning towards the XML implementation as it seems cleaner, can anyone else give their opinion?
I don't know regarding memory efficiency, but Here's my approach.
I don't like it, It requires multiple if-else (or switch) inside your onClick if you have multiple buttons
I use this if the 3rd option causes my method, for example onCreate() to be too big and messy
My favorite. it allows you to find out what each button does very easily, but I use it usually if its onClick isn't too long, to keep the code readable
I hardly use it, it keeps the code cleaner, but I'm not used to this one, since I don't use it in Java's SWING.
But in the bottom line, like #Lazy_Ninja said, it all comes down to taste. All 4 of them works.
I think what matters, when choosing, is keeping the code clean and readable.
Well it depends. At first I used to like the number 1(Make your Activity implement an OnClickListener interface) because the source look neat that way. But at the end I settled with 2.Inner Class OnClickListener, because I found it more easier to read and more easier to implement, especially if you use eclipse and know the shortcuts of auto completion.
At the end I think it depends on taste.