Code Structure

Introduction

Shipedge Warehouse Pro uses a hybrid architecture that combines traditional Android patterns with modern MVP (Model-View-Presenter) architecture. Understanding the code structure helps developers navigate the codebase, locate features, and maintain consistency when adding new functionality.

This guide explains:

• Overall project organization
• Package structure and naming conventions
• Legacy vs MVP architecture patterns
• Module organization
• Resource file structure
• Common patterns and conventions

Project Overview

Package Name

All code is organized under the shipedge.rep package. This is the main package containing all Activities, models, and utilities.

Hybrid Architecture

The project uses both legacy Android patterns (Activities + AsyncTasks) and modern MVP architecture. MVP is used in newer modules like Cycle Count and Load & Move.

229 Java Files

The main package contains 229 Java files organized by feature and responsibility. Most legacy features are in the root package, while MVP modules have their own subdirectories.

Resource Organization

Android resources (layouts, strings, images) are organized in the standard Android res/ directory structure with 171 layout XML files.

Directory Structure

Root Level

pro/
├── AndroidManifest.xml          # App configuration, permissions, activities
├── build.gradle                # Dependencies and build configuration
├── gradle.properties           # Gradle properties (AndroidX, Jetifier)
├── project.properties          # Target SDK configuration
├── proguard-project.txt        # ProGuard obfuscation rules
├── lint.xml                    # Lint rules
├── src/                        # Source code
├── res/                        # Android resources
├── libs/                       # Local JAR libraries
└── release/                    # Release APKs

Source Code Structure

pro/src/shipedge/rep/
├── [Main Activities]           # Core feature Activities
├── [MVP Modules]               # Modern MVP architecture modules
├── [API Classes]               # Server connection classes
├── [Data Models]               # POJOs and data classes
├── [Adapters]                  # ListView adapters
├── [Utilities]                 # Helper classes and services
└── [Other Components]          # Additional components

Main Package Organization

Core Activities

These Activities handle the main warehouse operations:

Entry Point:

• ReplenishmentActivity.java - Login screen and app launcher

Main Menu:

• AppMenu.java - Main navigation menu showing available features

Core Operations:

• MyRep.java - Replenishment operations (4133 lines, largest file)
• PickActivity.java - Picking and packing operations
• QualityControl.java - Quality control operations
• BinesActivity.java - Bins management
• ReturnActivity.java - Returns processing
• Transfers.java - Transfer operations
• TimeTrack.java - Time tracking by project
• BlindCount.java - Blind count operations
• Wall.java - Wall module

Hardware Integration:

• CameraActivity.java - Camera usage for barcode scanning
• MyWebView.java - WebView component

API Connection Classes

All server communication classes follow naming patterns:

Legacy Pattern:

• ConnectToDataBaseServer*.java - Main API connection classes
• ConnecToDataBaServer*.java - Variant naming (legacy)
• ConnectToDataBaseServer*Async.java - AsyncTask-based connections

Examples:

• ConnectToDataBaseServerLoginAsync.java - Login authentication
• ConnectToDataBaseServerReplenishment.java - Replenishment API
• ConnectToDataBaseServerReturn.java - Returns API
• ConnectToDataBaseServerToPickAsync.java - Picking API
• ConnectToDataBaseServerTimeTracker.java - Time tracking API

Modern Pattern (MVP Modules):

• CycleCountAPI.java - Cycle Count API client
• LoadMoveBinAPI.java - Load & Move API client

Data Models

POJOs (Plain Old Java Objects) represent data structures:

Core Models:

• Users.java - User information and session data (static class)
• Order.java - Order data structure
• Product.java - Product information
• Bin.java - Bin/location data
• Account.java - Account/customer data
• Location.java - Location data
• Lpn.java - License Plate Number data
• Replenishment.java - Replenishment request data

Other Models:

• Device.java - Device information
• LogPick.java - Pick logging data
• LogProject.java - Project logging data
• Multibox.java - Multi-box packaging data

Adapters

ListView adapters follow the pattern MyAdapter*.java:

Common Adapters:

• MyAdapter.java - Base adapter
• MyAdapterListOrder.java - Order list adapter
• MyAdapterListBinToReple.java - Replenishment bin list
• MyAdapterQC.java - Quality control adapter
• MyAdapterSerialList.java - Serial number list
• MyAdapterTimeTrack.java - Time tracking adapter

Total: 45+ adapter classes for various ListViews

Utilities and Services

Hardware Services:

• Datasource.java - Bluetooth scanner data handler
• MySocket.java - Bluetooth socket management
• ConnectDevice.java - Bluetooth device connection

Utility Classes:

• utils/UtilService.java - General utility methods
• utils/HttpResponse.java - HTTP response handling
• utils/VibratorService.java - Vibration service

Other Services:

• NotificationService.java - Notification handling
• Connector.java - Generic connector
• VerifyNet.java - Network verification

MVP Module Structure

Two modules use modern MVP architecture: Cycle Count and Load & Move.

Cycle Count Module

Location: cycleCountActivity/

Structure:

cycleCountActivity/
├── mainModule/                  # Main screen module
│   ├── view/
│   │   ├── CycleCountActivity.java
│   │   ├── CycleCountView.java
│   │   └── adapters/
│   ├── model/
│   │   ├── CycleCountInteractor.java
│   │   └── CycleCountInteractorClass.java
│   ├── presenter/
│   │   ├── CycleCountPresenter.java
│   │   └── CycleCountPresenterClass.java
│   ├── events/                  # Event callbacks
│   └── response/                # Response POJOs
├── detailModule/                # Detail screen module
│   ├── view/
│   │   └── CycleCountDetailFragment.java
│   ├── model/
│   │   └── CycleCountDetailInteractor.java
│   └── presenter/
│       └── CycleCountDetailPresenter.java
├── common/                      # Shared components
│   ├── dataAccess/
│   │   ├── CycleCountAPI.java
│   │   └── CycleCountService.java
│   └── params/                  # Request parameters
├── dto/                         # Data Transfer Objects
└── pojo/                        # Plain Old Java Objects

MVP Pattern:

• View: Activities and Fragments implement view interfaces
• Presenter: Handles business logic and coordinates between view and model
• Model/Interactor: Handles data operations (API calls, database)
• Events: Callback interfaces for async operations

Load & Move Module

Location: loadAndMoveActivity/

Structure:

loadAndMoveActivity/
├── mainModule/
│   ├── view/
│   │   └── LoadAndMoveActivity.java
│   └── uiMain/                  # UI components
├── blockedBinModule/           # Blocked bins feature
│   ├── view/
│   ├── model/
│   ├── presenter/
│   └── events/
├── putAwayModule/              # Put away feature
│   ├── view/
│   ├── model/
│   ├── presenter/
│   ├── events/
│   └── pojo/
├── putAwayDetailModule/        # Put away detail
│   └── awayOptionsModule/
├── refilModule/                 # Refill feature
├── common/                      # Shared components
│   ├── dataAccess/
│   │   ├── LoadMoveBinAPI.java
│   │   ├── LoadMoveBinService.java
│   │   └── LoadMoveBinDB.java
│   ├── events/
│   └── params/
└── dto/                         # Data Transfer Objects

Features:

• Multiple feature modules (blocked bins, put away, refill)
• Shared common components
• Local database (LoadMoveBinDB.java)
• Retrofit-based API clients

Architecture Patterns

Legacy Pattern (Most Features)

Structure:

Activity → AsyncTask → API Class → Server
         ↓
    SQLite Database

Characteristics:

• Activity contains UI and business logic
• AsyncTask handles background API calls
• Direct SQLite database access
• No separation of concerns
• Harder to test

Example: MyRep.java, PickActivity.java, QualityControl.java

MVP Pattern (New Modules)

Structure:

View (Activity/Fragment)
    ↓
Presenter (Business Logic)
    ↓
Interactor (Data Operations)
    ↓
API Service → Server
    ↓
Database Helper

Characteristics:

• Clear separation of concerns
• View interfaces for testability
• Presenter coordinates between view and model
• Interactor handles data operations
• Easier to test and maintain

Example: cycleCountActivity/, loadAndMoveActivity/

Resource Organization

Layout Files

Location: pro/res/layout/

Total: 171 XML layout files

Naming Convention:

• activity_*.xml - Activity layouts
• fragment_*.xml - Fragment layouts
• item_*.xml - ListView item layouts
• dialog_*.xml - Dialog layouts

Examples:

• activity_replenishment.xml
• activity_app_menu.xml
• fragment_cycle_count_detail.xml
• item_order_list.xml

String Resources

Location: pro/res/values/strings.xml

Usage:

• All UI text should come from string resources
• Referenced in Java: getString(R.string.resource_name)
• Referenced in XML: @string/resource_name

Important: Always check strings.xml for exact UI terminology when documenting features.

Other Resources

Values:

• arrays.xml - String arrays for spinners and lists
• dimen.xml - Dimension values
• styles.xml - App themes and styles
• colors.xml - Color definitions

Drawables:

• drawable-mdpi/, drawable-hdpi/, drawable-xhdpi/, etc. - Images by density
• drawable/ - Vector drawables and XML drawables

Menus:

• menu/ - Menu XML files

Naming Conventions

Classes

Activities:

• *Activity.java - Main Activities (e.g., PickActivity.java)
• *Fragment.java - Fragments (e.g., CycleCountDetailFragment.java)

API Classes:

• ConnectToDataBaseServer*.java - Server connection classes
• *API.java - Modern API clients (MVP modules)
• *Service.java - Retrofit service interfaces

Models:

• PascalCase for class names (e.g., Order.java, Product.java)
• POJOs match server response structure

Adapters:

• MyAdapter*.java - ListView adapters
• Descriptive suffix (e.g., MyAdapterListOrder.java)

Presenters (MVP):

• *Presenter.java - Presenter interface
• *PresenterClass.java - Presenter implementation

Interactors (MVP):

• *Interactor.java - Interactor interface
• *InteractorClass.java - Interactor implementation

Packages

Main Package:

• shipedge.rep - Root package

Subpackages:

• shipedge.rep.utils - Utility classes
• shipedge.rep.cycleCountActivity.* - Cycle Count MVP module
• shipedge.rep.loadAndMoveActivity.* - Load & Move MVP module
• shipedge.rep.providers - Content providers

File Organization Patterns

Single Responsibility

Each class should have a single, clear responsibility:

Good:

• ConnectToDataBaseServerReplenishment.java - Only handles replenishment API calls
• MyAdapterListOrder.java - Only adapts order data for ListView

Avoid:

• Classes that mix UI, business logic, and data access
• “God classes” that do everything

Feature-Based Organization

Legacy Features:

• All code in root package (shipedge.rep)
• Related classes grouped by naming convention

MVP Features:

• Each feature in its own subdirectory
• Clear module boundaries
• Shared code in common/ subdirectory

Code Size Guidelines

Large Files:

• MyRep.java - 4133 lines (legacy, needs refactoring)
• Most Activities - 500-2000 lines

MVP Modules:

• Smaller, focused classes
• Presenters: 200-500 lines
• Interactors: 200-400 lines
• Views: 300-800 lines

Common Patterns

API Call Pattern (Legacy)

// In Activity
AsyncTask task = new ConnectToDataBaseServerReplenishment(uomBarcode);
task.execute();
// Handle response in callback or check result

API Call Pattern (MVP)

// In Presenter
interactor.getData(params, new EventCallback() {
    @Override
    public void onSuccess(Data data) {
        view.showData(data);
    }

    @Override
    public void onError(String error) {
        view.showError(error);
    }
});

Database Pattern

Legacy:

SQLiteDatabase db = openOrCreateDatabase("database_name", MODE_PRIVATE, null);
db.execSQL("CREATE TABLE IF NOT EXISTS ...");

MVP:

// Database helper class
LoadMoveBinDB db = new LoadMoveBinDB(context);
db.insertBin(bin);

Event Bus Pattern (MVP)

// Post event
EventBus.getDefault().post(new CycleCountEvent(data));

// Subscribe
@Subscribe
public void onEvent(CycleCountEvent event) {
    // Handle event
}

Best Practices

Use MVP for New Features

When adding new features, use the MVP pattern like Cycle Count and Load & Move modules. It provides better separation of concerns and testability.

Follow Naming Conventions

Use established naming patterns: ConnectToDataBaseServer* for API classes, MyAdapter* for adapters, *Activity.java for Activities.

Organize by Feature

Group related classes together. For MVP modules, use feature-based subdirectories with clear module boundaries.

Keep Classes Focused

Each class should have a single responsibility. Avoid “God classes” that mix UI, business logic, and data access.

Use String Resources

Always use strings.xml for UI text. Never hardcode strings in Java code or XML layouts.

Document Complex Logic

Add comments for complex business logic, especially in legacy code. MVP pattern makes code self-documenting through clear separation.

Migration Strategy

Legacy to MVP

When refactoring legacy features to MVP:

1. Create Module Structure:

   • Create feature subdirectory
   • Set up mainModule/, common/, dto/, pojo/ directories

2. Extract View:

   • Create view interface
   • Move UI logic to Activity/Fragment implementing interface

3. Create Presenter:

   • Extract business logic from Activity
   • Create presenter interface and implementation

4. Create Interactor:

   • Extract data operations
   • Move API calls to interactor
   • Create database helpers if needed

5. Update API:

   • Convert to Retrofit service if needed
   • Create API client class

6. Test:

   • Test presenter logic independently
   • Test view updates
   • Test data operations

Code Statistics

Total Java Files: 229 in main package

By Type:

• Activities: ~20 main Activities
• API Classes: ~40 connection classes
• Adapters: 45+ adapter classes
• Models: ~30 POJO classes
• Utilities: ~10 utility classes
• MVP Modules: 2 complete modules

File Sizes:

• Largest: MyRep.java (4133 lines)
• Average Activity: 500-2000 lines
• Average MVP Presenter: 200-500 lines

Architecture:

• Legacy: ~90% of codebase
• MVP: ~10% (Cycle Count, Load & Move)

Related Documentation

• Architecture Overview - Overall architecture patterns
• API Reference - API endpoint documentation
• Contributing - Guidelines for contributing code