Application de service PC sur demandeOn-Demand PC Service App

Le problèmeThe problem

Les ateliers de réparation de PC gèrent leurs commandes entre plusieurs rôles sans système commun. L'inventaire se désynchronise, personne ne sait vraiment où en est une commande, et les passations entre employés se font à la main.

Notre réponse : une application par rôle, où chaque personne ne voit que les écrans dont elle a besoin. Les commandes passent par des états définis, et l'inventaire se met à jour en temps réel via Firestore.

PC repair shops handle orders across several staff roles without a shared system. Inventory drifts out of sync, nobody is sure what state an order is in, and handoffs between people happen by hand.

Our answer was a role-based app where each person only sees the screens they need. Orders move through defined states, and inventory updates in real time through Firestore.

RôlesRoles

ArchitectureHow it's built

Trois couches. Une activité par écran (LoginActivity, AdminDashboard, OrderActivity, InventoryActivity) ; une couche logique avec AuthManager, OrderController, InventoryManager et RoleRouter ; et en dessous, Firebase Auth avec deux collections Firestore (commandes et inventaire).

On a tout modélisé en UML avant de coder : un diagramme de classes (un User abstrait avec une sous-classe par rôle, plus Order, Component, Inventory), un diagramme de séquence du parcours complet d'une demande, un diagramme d'activité avec un couloir par rôle, et un diagramme d'états pour le cycle de vie d'une commande :

Three layers. Activities for each screen (LoginActivity, AdminDashboard, OrderActivity, InventoryActivity); a logic layer with AuthManager, OrderController, InventoryManager and RoleRouter; and Firebase Auth plus two Firestore collections (orders and inventory) underneath.

We designed it in UML before writing code: a class diagram (an abstract User with a subclass per role, plus Order, Component, Inventory), a sequence diagram of the full request flow, an activity diagram with one swim-lane per role, and a state diagram for the order lifecycle:

PENDING → APPROVED → IN_PROGRESS → ASSEMBLED → DELIVERED

Extraits de codeSome code

Après la connexion, chaque utilisateur est redirigé vers l'écran de son rôle :

After login, each user is sent to the screen for their role:

public static void routeUser(Context ctx, String role) {
    Intent intent;
    switch (role) {
        case "ADMIN":       intent = new Intent(ctx, AdminActivity.class); break;
        case "STOREKEEPER": intent = new Intent(ctx, StoreKeeperActivity.class); break;
        case "ASSEMBLER":   intent = new Intent(ctx, AssemblerActivity.class); break;
        default:            intent = new Intent(ctx, RequesterActivity.class); break;
    }
    ctx.startActivity(intent);
}

Une nouvelle commande passe à l'état PENDING, et les storekeepers sont notifiés une fois l'écriture confirmée par Firestore :

Submitting an order sets it to PENDING and notifies the storekeepers once Firestore confirms the write:

public void submitOrder(Order order, String requesterId) {
    order.setStatus(OrderStatus.PENDING);
    order.setRequesterId(requesterId);
    order.setTimestamp(System.currentTimeMillis());
    db.collection("orders")
        .add(order.toMap())
        .addOnSuccessListener(ref -> { order.setId(ref.getId()); notifyStoreKeepers(order); })
        .addOnFailureListener(e -> Log.e(TAG, "Order submit failed", e));
}

Les écrans d'inventaire écoutent Firestore directement : un changement sur un appareil apparaît tout de suite sur les autres.

Inventory screens listen to Firestore directly, so a change on one device shows up on the others right away:

public void listenToInventory(InventoryCallback callback) {
    db.collection("inventory")
        .whereEqualTo("available", true)
        .addSnapshotListener((snapshots, error) -> {
            if (error != null || snapshots == null) return;
            List<Component> items = new ArrayList<>();
            for (QueryDocumentSnapshot doc : snapshots)
                items.add(doc.toObject(Component.class));
            callback.onInventoryUpdated(items);
        });
}

Captures d'écranScreenshots

RésultatOutcome

• Application Android fonctionnelle sur un backend Firebase en production, testée avec les quatre rôles.
• Documentation UML complète (quatre types de diagrammes), validée par le professeur.
• Équipe de cinq coordonnée avec GitHub et des réunions hebdomadaires.

• Working Android app on a live Firebase backend, tested with all four roles.
• Full UML documentation (four diagram types), validated by the course instructor.
• Five-person team coordinated through GitHub and weekly syncs.

Java · Android Studio · Firebase Auth · Firestore · UML (draw.io) · GitHub