I'm just getting into my first android application and just wondering what the convention is here?
Is it more organised to separate my code into various packages? For example.
com.myfirstapp.activity;
com.myfirstapp.database;
I was thinking of doing this as a way of organising my code with database helper files for example kept it .database package.
I have just noticed that data is stored in /data/data/YOUR_PACKAGE/ does this mean that when on a device I would end up having data stored all over the place if I use different packages?
If this is not right what is a better way of organising code in Eclipse much like you do in Xcode?
Yes, please separate your code into packages. That's a beautiful concept of Java.
The file name your app is stored under is determined by manifest package element (which will be com.myfirstapp in your case).
Also have a look at Declaring class names section.
All your source file are stored int the src folder of your project. In the apk that is generated all your classes seem to be merged to a classes.dex file.
Keep your classes in the res folder and organize them into as many packages as you think you need. I normally have a data package that contains my data classes, packages like sound, database, location... that contain classes/controller for this various topics and then I have a ui package that holds several sub packages for the main branches in my User Interface.
Related
Since my application is growing more and more dense each day. I thought of re-structuring various files.
By re-structuring, I mean to add folders seperately for screen activites, another folder for dialog xmls, screen xmls, for custom adapters, etc. In other words, I need to segregate files according to their significance.
Currently, all my java files are listed in src folder (screen activities, custom adapters, business logic, etc.) and all the xmls (screens, custom list view design, custom dialogs, etc.) are present in layout folder.
Is it feasible? What impact will it have on the existing project?
Folders are synonymous with packages -- that's how the IDE interprets them. So putting them in separate folders actually creates separate packages. That's the downside, they won't have the same scope/permissions as if they were in the same package.
Packages in Java
What you're talking about is most likely packages.
Packages makes structuring of bigger projects and navigating through it much easier.
However you can't without writing your own gradle extension put your XML files outside /res/ folder, but codewise, wrapping your classes in packages makes working in bigger codebase much easier
You define the package you class is in before defining the imports in following way:
package com.ruuhkis.test;
import android.content.Context;
class Test {
}
then the Test class is put in folder /src/com/ruuhkis/test/ folder to be found by the compiler
When I make an app with package name com.example.app, src/com/example/app/MainActivity.java is created automatically. I am new to Java and I don't understand
why it uses so many folders inside folders? Why isn't it just src/MainActivity.java?
In order to avoid namespace collisions and conflicts, it's a common best practice in Java nest source code within a folder structure that is the reverse of the internet site associated with it. If everyone created jar library files in the root /src directory, eventually you'd have a collision and the code wouldn't be usable.
For instance, if I have some fancy Android library and I provided a class called Button, in a Button.java class, and you also at times wanted to use some other library that also had a Button.java in /src, your project would not compile.
Thus, in order to let everyone have their own unique Button class, the convention that was adopted was for everyone to use their reverse domain name, followed often by the project name. So the Facebook SDK, fo instance, has /src/com/facebook/android/Util.java while my own project has /src/com/myapp/misc/Util.java and I can use and reference both in my source code.
We hope to build multiple applications based on the same source code. The base source code will be stored in SVN so at daily development we just need to modify one codebase.
While for different customers, we hope to given some some level of branding. Mostly changing images and titles, these can be done by just change the resources.
After some research, We find that it is really touch to do these multiple version applications. The main problem is that R.java is generated based on the package name. And package name identify the application. In the source code there are many files import this package.name.R, which means for different application, there will be different package name, and different R's reference need to be change in most source code file.
We find some articles on web about using Ant to do this task, but none of them are really specified. We hope someone could help!
Generally the workflow will be like this:
Changing the package name in AndroidManifest.xml
Go over all source code file, find and replace anything referenced to R to the new package name.
Switch the res folder to the new client's res folder (We will have this folder ready)
Auto generate R.java file.
Start normal compile and build process.
Get Apk.
We hope someone could point out how can we achieve these task by using Ant, or any other better solution.
Thank you!
I think you should create an Android Library Project (http://developer.android.com/tools/projects/index.html#LibraryProjects) with the common code, check it into VCS, and then create separate projects for every customer which you should also check into VCS to keep track of them.
You will be able to generate different customized versions from same source code.
My goal is to create multiple android APKs. All that is different is the package name and I manually override some things in the res folder.
I understand you can do a library project. The problem with that is we have to manage multiple manifest files and the version with that. That is not what I want to do.
I was looking into aapt to create the new package name and shared res folder. The problem is I do not know where to start. I see lots of examples like:
Custom Android build.xml for rename manifest package
also below is exactly what I want to do:
http://blog.uncommons.org/2010/07/19/building-two-versions-of-the-same-android-app/
Can anyone provide direction on where to start?
The best way to do this is to create a library project, and than create separate projects for each of the APKs that you want to have. Each APK project can than have its own Manifest and reference the Library Project. Believe me when I tell you that this is much easier than trying to rename packages during build/compile time. You can easily call into activities that are shared in the library package just as long as you use the fully qualified name in the individual APK's manifest file.
http://developer.android.com/tools/projects/projects-eclipse.html
I had the same problem before and made a batch file to copy files like images, mp3 files, etc. to the workspace folder where I have my application folder in it. You have to make everything dynamic if you don't want to use the library project. I hope this helps, else you can ask me anything you want.
I have 3 editions of my android app. one free with ads, one paid and one branded with company CI.
so the difference betwenn them is minimal.
what is the best practice to manage multiple editions of this app.
one project, in code if (editionA) { ... }
multiple projects, reference common code in extra project
or something else ?
Update on the link and detailed description;
1. Library Modules
2. Setting up Library Project
Use an Android library project for the common code, with tiny projects for each specific flavor.
I do something similar with my apps. Common code base, several different sets of resources. I have a python script that copies my generic source from a common location to the src directory, copies the res_project directories to the res directory, updates the package names to reflect the new application package and update the AndroidManifest with the appropriate values.
I felt like there should have been a better way to do this, since your resources are already nicely segregated from your source, but had problems with an application package name that differed from my src package name. I blogged about that process in detail here.
I'd say 2, makes for the most flexibility + you can have different package names so your able to have them all installed at the same time on you device (if you want/need to)
Create a Master activity that has all the functionality, use sub activities and layouts for the 3 types of access?
This way you only have to maintain 1 project and core functionality.
Just have an initializer on start up which detects which activity to start.