In computing, a directory structure is the way an operating system's file system and its files are displayed to the user. Files are typically displayed in a hierarchical tree structure.
Android Application Modules are the modules that eventually get built into the .apk files based on your build settings. They contain things such as application source code and resource files. Most code and resource files are generated for you by default, while others should be created if required.
The following directories and files comprise an Android application module:
build/
Contains build folders for the specified build variants. Stored in the main application module.
libs/
Contains private libraries. Stored in the main application module.
src/
Contains your stub Activity file, which is stored at src/main/java//ActivityName>.java. All other source code files (such as .java or .aidl files) go here as well.
androidTest/
Contains the instrumentation tests.
main/java/com.>project<.>app<
Contains Java code source for the app activities.
main/jni/
Contains native code using the Java Native Interface (JNI).
main/gen/
Contains the Java files generated by Android Studio, such as your R.java file and interfaces created from AIDL files.
main/assets/
This is empty. You can use it to store raw asset files. Files that you save here are compiled into an .apk file as-is, and the original filename is preserved. You can navigate this directory in the same way as a typical file system using URIs and read files as a stream of bytes using the AssetManager.
main/res/
Contains application resources, such as drawable files, layout files, and string values in the following directories.
anim/
For XML files that are compiled into animation objects.
color/
For XML files that describe colors.
drawable/
For bitmap files (PNG, JPEG, or GIF), 9-Patch image files, and XML files that describe Drawable shapes or Drawable objects that contain multiple states (normal, pressed, or focused).
mipmap/
For app launcher icons. The Android system retains the resources in this folder (and density-specific folders such as mipmap-xxxhdpi) regardless of the screen resolution of the device where your app is installed. This behavior allows launcher apps to pick the best resolution icon for your app to display on the home screen. For more information about using the mipmap folders, see Managing Launcher Icons as mipmap Resources.
layout/
XML files that are compiled into screen layouts (or part of a screen).
menu/
For XML files that define application menus.
raw/
For arbitrary raw asset files. Saving asset files here is essentially the same as saving them in the assets/ directory. The only difference is how you access them. These files are processed by aapt and must be referenced from the application using a resource identifier in the R class. For example, this is a good place for media, such as MP3 or Ogg files.
values/
For XML files that define resources by XML element type. Unlike other resources in the res/ directory, resources written to XML files in this folder are not referenced by the file name. Instead, the XML element type controls how the resources defined within the XML files are placed into the R class.
xml/
For miscellaneous XML files that configure application components. For example, an XML file that defines a PreferenceScreen, AppWidgetProviderInfo, or Searchability Metadata.
AndroidManifest.xml
The control file that describes the nature of the application and each of its components. For instance, it describes: certain qualities about the activities, services, intent receivers, and content providers; what permissions are requested; what external libraries are needed; what device features are required, what API Levels are supported or required; and others.
.gitignore/
Specifies the untracked files ignored by git.
app.iml/
IntelliJ IDEA module
build.gradle
Customizable properties for the build system. You can edit this file to override default build settings used by the manifest file and also set the location of your keystore and key alias so that the build tools can sign your application when building in release mode. This file is integral to the project, so maintain it in a source revision control system.
proguard-rules.pro
ProGuard settings file.
In iOS, there is no industry standard as such. You could look into sample Apple Source Projects to see how they do it..
To keep all those hundreds of source files ending up in the same directory, it's a good idea to set up some folder structure depending on your architecture. For instance, you can use the following:
├─ Models
├─ Views
├─ Controllers
├─ Stores
├─ Helpers
Organize all Controllers in One Group with Subgroup for each usecase.
Put all views in One Group and subgroup for each usecase.
Organize All Models in one Group
Put Third Party Libraries in Another Group with Subgroup for each Lib.
So on and So Forth.. Also, associate each group to a folder inside your project.
Have a look on below example,
+ App
|
|-- .gitignore
|-- readme.md
|-- license.txt
|
+-+ App.xcodeproj
| +-- project.pbxproj
|
+-+ App
| +-+ Classes
| | |-- AppDelegate.h
| | |-- AppDelegate.m
| | |-- ViewController.h
| | |-- ViewController.m
| | +-- ViewController.xib
| |
| +-+ Resources
| | |-- Info.plist
| | |-- App.entitlements
| | |-- About.html
| | +-+ en.lproj
| | | +-- InfoPlist.strings
| | +-+ de.lproj
| | | +-- InfoPlist.strings
| | +-+ Images
| | |-- Default.png
| | +-- Default@2x.png
| |
| +-+ Other Sources
| | |-- App-prefix.pch
| | +-- main.m
| |
| +-+ External
| +-+ AFNetworking
| | |-- SomeFile.h
| | +-- SomeFile.m
| +-+ Sparkle
| |-- SomeOtherFile.h
| +-- SomeOtherFile.m
|
+-+ AppTests
+-+ Classes
| |-- TestCase1.h
| +-- TestCase1.m
|
+-+ Resources
|-- InfoPlist.strings
+--AppTests-Info.plist
If you're planning on including external dependencies (e.g. third-party libraries) in your project, CocoaPods offers easy and fast integration. Note in that case, you'll need to open the
Android Application Modules are the modules that eventually get built into the .apk files based on your build settings. They contain things such as application source code and resource files. Most code and resource files are generated for you by default, while others should be created if required.
The following directories and files comprise an Android application module:
build/
Contains build folders for the specified build variants. Stored in the main application module.
libs/
Contains private libraries. Stored in the main application module.
src/
Contains your stub Activity file, which is stored at src/main/java//ActivityName>.java. All other source code files (such as .java or .aidl files) go here as well.
androidTest/
Contains the instrumentation tests.
main/java/com.>project<.>app<
Contains Java code source for the app activities.
main/jni/
Contains native code using the Java Native Interface (JNI).
main/gen/
Contains the Java files generated by Android Studio, such as your R.java file and interfaces created from AIDL files.
main/assets/
This is empty. You can use it to store raw asset files. Files that you save here are compiled into an .apk file as-is, and the original filename is preserved. You can navigate this directory in the same way as a typical file system using URIs and read files as a stream of bytes using the AssetManager.
main/res/
Contains application resources, such as drawable files, layout files, and string values in the following directories.
anim/
For XML files that are compiled into animation objects.
color/
For XML files that describe colors.
drawable/
For bitmap files (PNG, JPEG, or GIF), 9-Patch image files, and XML files that describe Drawable shapes or Drawable objects that contain multiple states (normal, pressed, or focused).
mipmap/
For app launcher icons. The Android system retains the resources in this folder (and density-specific folders such as mipmap-xxxhdpi) regardless of the screen resolution of the device where your app is installed. This behavior allows launcher apps to pick the best resolution icon for your app to display on the home screen. For more information about using the mipmap folders, see Managing Launcher Icons as mipmap Resources.
layout/
XML files that are compiled into screen layouts (or part of a screen).
menu/
For XML files that define application menus.
raw/
For arbitrary raw asset files. Saving asset files here is essentially the same as saving them in the assets/ directory. The only difference is how you access them. These files are processed by aapt and must be referenced from the application using a resource identifier in the R class. For example, this is a good place for media, such as MP3 or Ogg files.
values/
For XML files that define resources by XML element type. Unlike other resources in the res/ directory, resources written to XML files in this folder are not referenced by the file name. Instead, the XML element type controls how the resources defined within the XML files are placed into the R class.
xml/
For miscellaneous XML files that configure application components. For example, an XML file that defines a PreferenceScreen, AppWidgetProviderInfo, or Searchability Metadata.
AndroidManifest.xml
The control file that describes the nature of the application and each of its components. For instance, it describes: certain qualities about the activities, services, intent receivers, and content providers; what permissions are requested; what external libraries are needed; what device features are required, what API Levels are supported or required; and others.
.gitignore/
Specifies the untracked files ignored by git.
app.iml/
IntelliJ IDEA module
build.gradle
Customizable properties for the build system. You can edit this file to override default build settings used by the manifest file and also set the location of your keystore and key alias so that the build tools can sign your application when building in release mode. This file is integral to the project, so maintain it in a source revision control system.
proguard-rules.pro
ProGuard settings file.
In iOS, there is no industry standard as such. You could look into sample Apple Source Projects to see how they do it..
To keep all those hundreds of source files ending up in the same directory, it's a good idea to set up some folder structure depending on your architecture. For instance, you can use the following:
├─ Models
├─ Views
├─ Controllers
├─ Stores
├─ Helpers
You could also, try organizing your files into Groups & associate each group to a folder..Organize all Controllers in One Group with Subgroup for each usecase.
Put all views in One Group and subgroup for each usecase.
Organize All Models in one Group
Put Third Party Libraries in Another Group with Subgroup for each Lib.
So on and So Forth.. Also, associate each group to a folder inside your project.
Have a look on below example,
+ App
|
|-- .gitignore
|-- readme.md
|-- license.txt
|
+-+ App.xcodeproj
| +-- project.pbxproj
|
+-+ App
| +-+ Classes
| | |-- AppDelegate.h
| | |-- AppDelegate.m
| | |-- ViewController.h
| | |-- ViewController.m
| | +-- ViewController.xib
| |
| +-+ Resources
| | |-- Info.plist
| | |-- App.entitlements
| | |-- About.html
| | +-+ en.lproj
| | | +-- InfoPlist.strings
| | +-+ de.lproj
| | | +-- InfoPlist.strings
| | +-+ Images
| | |-- Default.png
| | +-- Default@2x.png
| |
| +-+ Other Sources
| | |-- App-prefix.pch
| | +-- main.m
| |
| +-+ External
| +-+ AFNetworking
| | |-- SomeFile.h
| | +-- SomeFile.m
| +-+ Sparkle
| |-- SomeOtherFile.h
| +-- SomeOtherFile.m
|
+-+ AppTests
+-+ Classes
| |-- TestCase1.h
| +-- TestCase1.m
|
+-+ Resources
|-- InfoPlist.strings
+--AppTests-Info.plist
If you're planning on including external dependencies (e.g. third-party libraries) in your project, CocoaPods offers easy and fast integration. Note in that case, you'll need to open the
.xcworkspace file instead of .xcproject, or your code will not compile. 
No comments:
Post a Comment