Skip to content

rranlevi/SmartHome_Client

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Smart Home Client - Group 8

Overview

This project is a Smart Home Server and Client implementation that facilitates the management and control of various household smart devices. The system is designed with a structured architecture that dynamically generates the user interface (UI) on the client side, based on the devices available and their states. The client fetching the devices data from the server, the server creates a mocking devices - but the project designed in a way that every data or action on a devices is a REST URL path, GET for data and POST for actions, in order to easily deploy to a real life scenario where the edge devices are real devices.

Key Features

  1. Dynamic Device Management

    The system provides robust management for a variety of household devices, each represented by a class in a well-structured hierarchy. From simple switches and sliders to more sophisticated components like live camera streams, the architecture allows for seamless addition, removal, and interaction with devices. The system's dynamic nature ensures that new devices can be integrated effortlessly, and existing devices can be managed efficiently, all within a unified framework.

  2. Server-Driven API and UI Interaction

    The server plays a critical role in handling device interactions and API endpoints, providing real-time updates to the client-side UI. By managing API endpoints dynamically based on the devices connected, the server ensures that the UI is always up-to-date with the latest device configurations and states. This approach eliminates the need for manual updates on the client side, as any changes made on the server are automatically reflected in the user interface, providing a consistent and responsive user experience.

  3. Persistent State and User Preferences

    The system is designed with a focus on user experience, offering persistent state management across sessions. User interactions, such as device configurations and selections, are saved by the server, allowing users to pick up right where they left off, even after logging out or disconnecting. This persistence extends to device settings, ensuring that the system remains tailored to individual preferences, enhancing usability and continuity for the end-user.

Project Requirements

  1. Collections:
    • ArrayList and List: Used extensively for managing collections of devices, actions, and device information. Examples include:
      • List<Info> in the Device class for storing device information.
      • List<DeviceAction> in the DeviceActionController class for managing device actions.
      • List<HouseholdDevice> in the Mocking class for creating and storing mock devices.
      • List<DeviceInfo> in the DeviceDataController class for holding device data.
  2. Abstract Classes:
    • Device: The Device class serves as an abstract base class for all device types, defining common properties and methods that are inherited by subclasses like HouseholdDevice.
  3. Classes:
    • A total of 22 unique classes are implemented, covering both server and client functionality. Key classes include Main, HouseholdDevice, DeviceAction, AddDevicesPanel, DataActionPanel, ServerController, and SharedDB.
  4. Iterators:
    • Used in several places for looping through collections, such as:
      • Iterating through the list of DeviceInfo in the DeviceDataController class.
      • Looping through DeviceAction objects in the DeviceActionController class.
      • Iterating through HouseholdDevice objects in the AddDevicesPanel and MainPanel classes.
  5. Containers:
    • Swing Containers: Used extensively in the client-side UI, such as:
      • JPanel in AddDevicesPanel and DataActionPanel for organizing UI components.
      • JScrollPane in AddDevicesPanel to allow scrolling through the table of devices.
      • CardLayout in the MainPanel class for switching between different views.
    • Collections: ArrayList and List are used as data containers throughout the project.
  6. Dynamic Functionality:
    • The project supports adding, removing, displaying, and sorting devices dynamically, as seen in:
      • The Main class, which dynamically adds endpoints and starts the server.
      • AddDevicesPanel, which allows users to add new devices, and sort them using comparators.
      • Mocking, where mock devices are dynamically created and added to a list.
  7. Inheritance:
    • Implemented with several classes, such as:
      • Device: An abstract class that serves as a base for HouseholdDevice.
      • Widget: A base class for UI widgets like Switch, Slider, and Dropdown.
      • CameraStream, Dropdown, and Slider all extend Widget.
  8. Polymorphism:
    • Used in managing different types of devices and actions, particularly in:
      • HouseholdDevice objects being referenced through the Device superclass.
      • Widget class serving as a base for different UI components like Switch, Slider, and Dropdown, allowing them to be used interchangeably.
  9. UI:
    • Extensive use of Swing components to build the client-side interface, such as:
      • JPanel, JLabel, JButton, JTable, and JScrollPane in AddDevicesPanel, DataActionPanel, and MainPanel.
      • Custom UI components like a gradient-colored slider in GradientSliderUI.
  10. Error-Catching Mechanism:
    • Error handling is implemented in several classes using try-catch blocks, such as:
      • ServerController for handling HTTP request errors.
      • RestWrapper for managing exceptions during HTTP communication between the client and server.
      • AddDevicesPanel and DataActionPanel for handling exceptions during UI updates and device actions.
  11. Comparators:
    • Used for sorting devices in:
      • AddDevicesPanel: Sorting devices by name or room.
      • MainPanel: Sorting devices by name or room using a Comparator<HouseholdDevice>.

Architectural Design

alt text|

The system follows a modular design, with each component playing a specific role:

  • Device Class: The base class for all devices, containing common attributes such as deviceName and description.
  • HouseholdDevice Class: Extends the Device class, designed so we can represent every new smart home device in the future, every device have dataController for device realtime data and actionController for sending commands:
    • Controllers: The DeviceActionController and DeviceDataController manage the actions and data related to devices. They ensure that commands and data flows are handled correctly and are kept in sync with the server.
  • Info and DeviceInfo Classes: Store information related to devices, which is used to generate the UI and manage device states.
  • DeviceAction and Widget Classes: Handle specific actions and UI elements associated with devices. These classes ensure that each device can interact with the user interface seamlessly, and it is the key-feature for scalability in our project (easy support for new devices in the future).

How to Use

  1. Setup: Clone the client and server repositories, first run the server then the client as shown in the video below.
  2. Add Devices: Add your household devices by opening a window with the server-connected devices through the button.
  3. Actions & Data: After adding devices from the server enter the Actions & Data page, send data to the devices through the server, and see live data.

Walkthrough Videos:

How.to.Run.and.Important.UI.Explanation.mp4
Application.mp4

UML Reference

alt text

Credits

This project was made possible by the contributions of the following individuals:

  • Ran Levi
  • Harel Markel
  • Alex Makarov
  • Ron Yamin

Licensing

Copyright (c) 2024 Ran Levi, Harel Markel, Alex Makarov, Ron Yamin

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Contributors 4

  •  
  •  
  •  
  •  

Languages