report:conc

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
report:conc [2026/06/13 16:45] – [8.2.1 Front-end] team1report:conc [2026/06/14 14:55] (current) – [8.2.2 Back-end] team1
Line 14: Line 14:
 The front-end is written in Flutter, an open source programming framework designed by Google and written in Dart. The widgets are split into multiple components following atomic design. By using atomic design, the developer can make big changes throughout the application by making macro changes. This also allows for categorization of widgets per function and size [(frost2016atomic)]. Both of these allow for faster workflow and separation of concern. The front-end is written in Flutter, an open source programming framework designed by Google and written in Dart. The widgets are split into multiple components following atomic design. By using atomic design, the developer can make big changes throughout the application by making macro changes. This also allows for categorization of widgets per function and size [(frost2016atomic)]. Both of these allow for faster workflow and separation of concern.
  
-As mentioned in the previous chapter, the developer of the team went through a careful process of of continuous user testing and wireframe development in order to create a design that matched the purpose as well as a design that was accessible. To attain both goals, the developer used the following apps for design reference:+As mentioned in the previous chapter, the developer of the team went through a careful process of of continuous user testing and wireframe development in order to create a design that matched the purpose as well as a design that was accessible. 
 + 
 +To attain both goals, the developer used the following apps for design reference:
  
   * Forest, an application that aims to help its users increase their productivity by growing a virtual forest.   * Forest, an application that aims to help its users increase their productivity by growing a virtual forest.
Line 20: Line 22:
   * Liven, a mental health application designed to increase in the user's relaxation and levels of serenity.   * Liven, a mental health application designed to increase in the user's relaxation and levels of serenity.
  
-== 8.2.1.1 UI ==+== 8.2.1.1 Comparative analysis == 
 +The team originally planned to write this app using Ionic Vue, but that idea quickly changed and instead the developer made the front-end using Flutter. Figure {{ref>comparative_analysis_frontend}} displays the parameters in which both frameworks were compared, which lead to the choice of Flutter. 
 + 
 +<WRAP center round box 100%> 
 +<WRAP> 
 +<table comparative_analysis_frontend> 
 +<caption>Front-end comparison (Flutter vs Ionic Vue)</caption> 
 +<WRAP> 
 + 
 +^ Category ^ Flutter ^ Ionic Vue ^ Reason for choosing Flutter ^ 
 +| Framework type | Native cross-platform framework | Hybrid framework (WebView-based) | Flutter provides better performance and a more native app experience | 
 +| Performance | Compiled to native code | Runs inside a WebView | Flutter offers smoother UI and better performance for real-time updates | 
 +| UI rendering | Own rendering engine (Skia) | HTML/CSS inside WebView | Flutter ensures consistent UI across Android and iOS | 
 +| Real-time sensor updates | Efficient UI rebuilding for frequent updates | Can lag with frequent DOM updates | Flutter handles continuous sensor streaming more efficiently | 
 +| Device integration | Strong plugin ecosystem for hardware features | Depends heavily on plugins and WebView bridges | Flutter simplifies access to device features needed for IoT monitoring | 
 +| Development focus | Mobile-first framework | Web-first framework adapted for mobile apps | Flutter is better suited for performance-critical mobile applications | 
 + 
 +</WRAP> 
 +</table> 
 +</WRAP> 
 +</WRAP> 
 + 
 + 
 +== 8.2.1.2 UI ==
  
 The wireframe was made with high-fidelity in mind, meaning it had its own housestyle before the final decision on housestyle for the eventual application. Because of this, the final product looks a bit different from what was shown during user testing. However, the main concepts stayed the same, being the colors, positioning of elements and edge design. The wireframe was made with high-fidelity in mind, meaning it had its own housestyle before the final decision on housestyle for the eventual application. Because of this, the final product looks a bit different from what was shown during user testing. However, the main concepts stayed the same, being the colors, positioning of elements and edge design.
Line 43: Line 68:
 Secondly, the settings icon isn't displayed anymore in the top right corner of the application. This can also be seen on figure {{ref>fig:comparison_scanning_page_wireframe_and_product}} and is applied to every page. Initially, there was an idea to keep that settings icon for the user to change their settings without needing to go to the profile page. This icon was removed with the idea in mind that it could potentially distract the user from each page's purpose. Secondly, 95% of users don't change any settings in apps or websites and stick to the default options [(catalanotto2019default)]. This space is now empy and could be user for other content, for example warning messages or in-app pop-up notifications. While the usage for this empty space is undecided, the space will simply stay empty. Secondly, the settings icon isn't displayed anymore in the top right corner of the application. This can also be seen on figure {{ref>fig:comparison_scanning_page_wireframe_and_product}} and is applied to every page. Initially, there was an idea to keep that settings icon for the user to change their settings without needing to go to the profile page. This icon was removed with the idea in mind that it could potentially distract the user from each page's purpose. Secondly, 95% of users don't change any settings in apps or websites and stick to the default options [(catalanotto2019default)]. This space is now empy and could be user for other content, for example warning messages or in-app pop-up notifications. While the usage for this empty space is undecided, the space will simply stay empty.
  
-== 8.2.1.2 Logics ==+== 8.2.1.3 Logics ==
  
 The original idea was for this application to be written in Ionic Vue JavaScript, but due to its taxing amount of energy on smaller devices that idea was quickly scrapped. The app is thus written in Flutter. The original idea was for this application to be written in Ionic Vue JavaScript, but due to its taxing amount of energy on smaller devices that idea was quickly scrapped. The app is thus written in Flutter.
Line 57: Line 82:
   WidgetsFlutterBinding.ensureInitialized();   WidgetsFlutterBinding.ensureInitialized();
   await Supabase.initialize(   await Supabase.initialize(
-    url: 'the URL of the supabase back-end', +    url: 'URL of the supabase back-end', 
-    anonKey: 'the anonymous',+    anonKey: 'anonymous supabase database key',
   );   );
   runApp(MainApp());   runApp(MainApp());
Line 110: Line 135:
   }   }
 </code> </code>
 +
 +=== 8.2.2 Back-end ===
 +The back-end is not written by the developer. Instead, the team uses Supabase, a cloud-based back-end solution which offers tools to handle database entries, policies and authentication. 
 +
 +== 8.2.2.1 Comparative analysis ==
 +Figure {{ref>comparative_analysis_backend}} explains the differences between using a self-written back-end and using an already existing cloud solution.
 +
 +<WRAP center round box 100%>
 +<WRAP>
 +<table comparative_analysis_backend>
 +<caption>Back-end comparison (Supabase vs custom back-end)</caption>
 +<WRAP>
 +
 +^ Category ^ Supabase ^ Custom back-end ^ Reason for choosing Supabase ^
 +| Development time | Ready-to-use backend platform | Requires full server development | Supabase significantly reduces development time |
 +| Hosting | Fully managed cloud hosting | Requires manual hosting setup | No need to manage servers or deployment infrastructure |
 +| Database management | Built-in PostgreSQL with dashboard tools | Requires manual database setup and maintenance | Easier database handling and configuration |
 +| Real-time features | Built-in real-time subscriptions | Requires WebSockets or polling implementation | Simplifies live sensor data updates |
 +| Authentication | Built-in authentication system | Must be implemented from scratch | Faster and more secure authentication setup |
 +| Ease of use | Provides dashboards, APIs, and tools | Requires custom implementation of all features | Easier overall backend workflow |
 +| Maintenance | Managed by Supabase | Fully maintained by developer/team | Reduces long-term maintenance workload |
 +| Scalability | Automatically scalable cloud infrastructure | Depends on custom server design | More reliable scaling without extra effort |
 +
 +</WRAP>
 +</table>
 +</WRAP>
 +</WRAP>
 +
 +== 8.2.2.2 Supabase tools ==
 +As mentioned before, Supabase offers various tools to make it easier to develop a product, allowing for greater focus on the front-end. One of these tools is built-in authentication logic with integration of third party account systems such as Google and Facebook. This form of authentication is encrypted, putting user data security as a top priority [(supabase2026auth)].
 +
 +Secondly, using Supabase means the team doesn't need to host their own back-end service. This saves resources such as time and money, allowing the team to put more resources in other aspects of the project, front-end and the plant pot for example. 
 +
 +Thirdly, Supabase allows for realtime table changes to be read from the front-end. This makes is very simple to display the live sensor data from the plant pot to the application. This functionality is called Supabase Realtime [(supabase2026realtime)].
 +
 +== 8.2.2.3 Push notifications using Firebase Cloud Messaging ==
 +
 +Push notifications are implemented by combining Supabase as the backend system with Firebase Cloud Messaging (FCM) as the delivery service. Supabase itself does not directly send push notifications to mobile devices. Instead, it is used to detect when a notification should be triggered, while FCM is responsible for delivering the notification to the user’s device.
 +
 +In this architecture, sensor data from the microcontroller is continuously stored in a Supabase database. When a new sensor reading is inserted, Supabase evaluates whether the value meets a predefined condition (for example, a temperature or humidity value falling below a safe threshold). This evaluation is typically handled using database triggers or server-side logic such as Edge Functions.
 +
 +Once a critical condition is detected, Supabase executes a server-side action that prepares a notification payload. This payload usually includes information such as the type of alert, sensor ID, timestamp, and severity level. Supabase then sends a request to Firebase Cloud Messaging using a secure server-to-server API call.
 +
 +Firebase Cloud Messaging acts as the messaging intermediary between the backend and the mobile application. It receives the notification request from Supabase and routes it to the correct device using a unique device token stored in the Supabase database. The device token is generated when the Flutter application first registers the user’s device with FCM and is linked to the user account in Supabase.
 +
 +FCM is capable of delivering notifications even when the application is closed or running in the background, as it operates at the operating system level. This ensures that critical sensor alerts are reliably delivered regardless of the application state. When the user receives the notification, they can tap it to open the application and navigate directly to the relevant sensor data or alert handling screen.
 +
 +This approach separates responsibilities clearly: Supabase manages data storage, real-time evaluation, and trigger logic, while Firebase Cloud Messaging handles cross-platform notification delivery.
 +=== 8.3 Flow charts ===
 +Using flow charts, the developer displays how the product flow goes for various functions. The functions are the ones listed below.
 +
 +  * Starting a focus session.
 +  * Manual watering of the plant.
 +  * Automated watering of the plant.
 +  * Switching the plant pot mode between manual and automated.
 +  * Reading data from the plant pot's sensors.
 +  * Sending a notification when the data read hits the danger zone.
 +  * Making a post for the garden.
 +
 +Figure {{ref>fig:flowchart_focus_session}} displays the flow chart for starting a focus session which keeps the plant growing and adds time to the user's focus time.
 +
 +<WRAP centeralign>
 +<figure fig:flowchart_focus_session>
 +{{ :report:app:flowchart_focus_session.png?nolink&600 |}}
 +<caption>Flow chart for starting a focus session in the app.</caption>
 +</figure>
 +</WRAP>
 +
 +Figure {{ref>fig:flowchart_manual_watering}} displays the flow chart for manually watering the plant when the moisture sensor detects low levels of moisture.
 +
 +<WRAP centeralign>
 +<figure fig:flowchart_manual_watering>
 +{{ :report:app:flowchart_manual_watering.png?nolink&600 |}}
 +<caption>Flow chart for manually watering the plant pot.</caption>
 +</figure>
 +</WRAP>
 +
 +Figure {{ref>fig:flowchart_automated_watering}} displays the flow chart for automated watering of the plant.
 +<WRAP centeralign>
 +<figure fig:flowchart_automated_watering>
 +{{ :report:app:flowchart_automated_watering.png?nolink&600 |}}
 +<caption>Flow chart for automatically watering the plant pot.</caption>
 +</figure>
 +</WRAP>
 +
 +Figure {{ref>fig:flowchart_mode_switch}} displays the flow chart for switching between watering mode of the plant.
 +
 +<WRAP centeralign>
 +<figure fig:flowchart_mode_switch>
 +{{ :report:app:flowchart_mode_switch.png?nolink&600 |}}
 +<caption>Flow chart for switching between manual and automated mode.</caption>
 +</figure>
 +</WRAP>
 +
 +Figure {{ref>fig:flowchart_read}} displays the flow chart for continuously reading from the sensors in the plant pot and sending the data to the database.
 +
 +<WRAP centeralign>
 +<figure fig:flowchart_read>
 +{{ :report:app:flowchart_reading_data.png?nolink&600 |}}
 +<caption>Flow chart for reading data from the sensors as a live stream.</caption>
 +</figure>
 +</WRAP>
 +
 +Figure {{ref>fig:flowchart_push}} displays the flow chart for sending a push notification to the user's phone when the sensors read data that's in the danger zone.
 +
 +<WRAP centeralign>
 +<figure fig:flowchart_push>
 +{{ :report:app:flowchart_push_notification.png?nolink&600 |}}
 +<caption>Flow chart for sending notifications to the user's phone.</caption>
 +</figure>
 +</WRAP>
 +
 +Figure {{ref>fig:flowchart_social_media}} displays the flow chart for posting an update on your plant to the social garden zone of the application.
 +
 +<WRAP centeralign>
 +<figure fig:flowchart_social_media>
 +{{ :report:app:flowchart_social_media.png?nolink&600 |}}
 +<caption>Flow chart for creating a post for the garden.</caption>
 +</figure>
 +</WRAP>
 +
 ===== 9. Conclusions ===== ===== 9. Conclusions =====
  
Line 126: Line 272:
 ==== 9.3 Future Development ==== ==== 9.3 Future Development ====
  
-Future work should focus on integrating and testing the identified low-pressure valve solution within the final product architecture. The water pump-based solution implemented during prototype development served as a practical workaround to continue testing and validation activities. However, the intended final product aims to maintain the original gravity-fed irrigation concept by utilizing a low-pressure valve that can operate without additional pumping. Preliminary analysis suggests that the replacement valve will overcome the pressure limitations encountered during prototype testing and enable the intended irrigation strategy. Experimental validation is nevertheless required to confirm system reliability, water delivery performance, and long-term operation. Additional testing using the intended cork-based housing is also recommended. This would allow evaluation of thermal behaviour, moisture resistance, structural durability, and overall product performance under realistic operating conditions. Such testing would provide valuable insights into the interaction between the irrigation system, electronic components, and sustainable construction materials.+Future work should focus on integrating and testing the identified low-pressure valve solution within the final product architecture. The water pump-based solution implemented during prototype development served as a practical workaround to continue testing and validation activities. However, the intended final product aims to maintain the original gravity-fed irrigation concept by utilizing a low-pressure valve that can operate without additional pumping. Preliminary analysis suggests that the replacement valve will overcome the pressure limitations encountered during prototype testing and enable the intended irrigation strategy. Experimental validation is nevertheless required to confirm system reliability, water delivery performance, and long-term operation. Additional testing using the intended cork-based housing is also recommended. This would allow evaluation of thermal behavior, moisture resistance, structural durability, and overall product performance under realistic operating conditions. Such testing would provide valuable insights into the interaction between the irrigation system, electronic components, and sustainable construction materials.
  
 Future work should also focus on optimizing the growing medium. During the project, sodium alginate and polyacrylamide were identified as promising materials for improving water retention and moisture distribution. Further experimentation should be conducted to determine the optimal mixture and porosity for supporting healthy plant growth and efficient water management. Future versions of Screen2Green could support a wider variety of plants and include additional environmental sensors for monitoring factors such as temperature, humidity, and water levels. Improvements to the mobile application, including enhanced user feedback, usage analytics, and personalization features, could further strengthen the connection between digital habits and plant care. Future work should also focus on optimizing the growing medium. During the project, sodium alginate and polyacrylamide were identified as promising materials for improving water retention and moisture distribution. Further experimentation should be conducted to determine the optimal mixture and porosity for supporting healthy plant growth and efficient water management. Future versions of Screen2Green could support a wider variety of plants and include additional environmental sensors for monitoring factors such as temperature, humidity, and water levels. Improvements to the mobile application, including enhanced user feedback, usage analytics, and personalization features, could further strengthen the connection between digital habits and plant care.
  
-Finally, a long-term user study should be conducted to evaluate the effectiveness of the biological feedback mechanism and determine whether the system contributes to lasting changes in smartphone usage behaviour. Such a study would provide valuable insight into the long-term impact of the concept and help validate its effectiveness as a tool for promoting digital wellbeing.+Finally, a long-term user study should be conducted to evaluate the effectiveness of the biological feedback mechanism and determine whether the system contributes to lasting changes in smartphone usage behavior. Such a study would provide valuable insight into the long-term impact of the concept and help validate its effectiveness as a tool for promoting digital wellbeing.
  • report/conc.1781365520.txt.gz
  • Last modified: 2026/06/13 16:45
  • by team1