Portable Bluetooth thermal printers are used to generate the mini receipts.
Dependencies
bluetooth_thermal_printer
js
Enable Bluetooth in the respective mobile device.
Switch the thermal printer.
Tap on the Print button from the respective screen if the printer device is connected already it will print the receipt directly or else it will show a dialogue with a list of Bluetooth devices, from their user need to a selected respective thermal printer, once the device is paired successfully it will generate a receipt in the printer.
printTicket → Used to write the bytes to the thermal printer if the device is connected otherwise it will show paired Bluetooth devices in a dialogue.
Required Arguments → bytes, context
getTicket → Used to generate the bytes from the Image and also set the paper size. Required Arguments → Image
showMyDialog → Used to show the Paired Bluetooth devices Required Arguments → bytes, context
setConnect → If the device is already connected it will generate the receipt or else it will show the paired devices to connect.
Integration testing (also called end-to-end testing or GUI testing) is used to simulate a user interacting with your app by doing things like clicking buttons, selecting items, scrolling items, etc. Integration testing is used to test how individual pieces work together as a whole or capture the performance of an application running on a real device.
integration_test
We declared the integration_test package in pubspec.yaml as shown in the image above.
The test_driver directory contains the integration_test_driver.dart file. (The folder structure is shown in the image above). The integration driver is called from this file.
The integration_test directory contains the test script files of different screens.
The Test Inputs directory contains the test_inputs.dart file. This file has the user action inputs in JSON format. We can change user actions in this file.
There are two ways to start the integration testing:
To run the integration test on a virtual emulator/mobile, run the command on your terminal : cd ./frontend/mgramseva && flutter drive --driver=test_driver/integration_test_driver.dart --target=integration_test/login_test.dart
(...or...)
Go to ./frontend/mgramseva/utils/execute_integration.sh and run the execute_integration.sh file on the virtual emulator/mobile. The integration test will start.
User actions Inputs - .frontend/mgramseva/integration_test/Test Inputs/test_inputs.dart
Integration Test Driver - .frontend/mgramseva/test_driver/integration_test_driver.dart
Execute Integration Test - .frontend/mgramseva/utils/execute_integration.sh
An introduction to integration testingflutterdev
GitHub Actions enables you to create custom software development lifecycle workflows directly in your GitHub repository. This enables you to include Continuous Integration (CI) and continuous deployment (CD) capabilities. It makes it easier to automate how you build, test, and deploy your projects on any platform, including Linux, macOS, and Windows.
Run your workflows in a virtual machine and a local machine as well.
It is easy to build the app in artefacts.
Analyze, build, test and deploy our applications on any platform.
Easily release the app bundle in the Play Store.
The speed of GitHub Actions is good.
GitHub Actions Documentation - GitHub DocsGitHub Docs
Github Actions for FlutterMedium
About self-hosted runners - GitHub DocsGitHub Docs
Primary Files - https://github.com/egovernments/punjab-mgramseva/blob/develop/frontend/mgramseva/lib/screeens/SelectLanguage/languageSelection.dart
Every command will be written in yml files and all these files will be in the .github/workflows/ directory of your repository, then only git will identify our script files.
In our repository we are maintaining this file as main.yml, In this yml file we are executing the android drive job, which will run the integration testing scripts, once all the tests are passed then only it will build the app in QA ENV and store it in the artefacts as shown image.
Explained every line of main.yml file with comments below.
We can host your runners and customize the environment used to run jobs in your GitHub Actions workflows. Self-hosted runners can be physical, virtual, in a container, on-premises, or a cloud.
With self-hosted runners, you can choose to create a custom hardware configuration with more processing power or memory to run larger jobs, install software available on your local network, and choose an operating system not offered by GitHub-hosted runners.
On https://github.com/ navigate to the main page of the repository.
Under your repository name, click Settings as shown in the image.
In the left sidebar, click Actions.
In the left sidebar, under "Actions", click Runners.
Click New self-hosted runner.
Select the operating system image and architecture of your self-hosted runner machine.
You will see instructions showing you how to download the runner application and install it on your self-hosted runner machine.
After completing the steps to add a self-hosted runner, the runner and its status are now listed under "Runners".
Now you will have to edit the main.yaml file for using our local machine, replace the runs on with self-hosted as shown below.
runs-on: ubuntu-latest >> runs-on: self-hosted
Google Analytics helps you understand how people use the web and Android apps. Analytics helps you understand how the users behave, so we can make informed decisions about how to market our app.
firebase_analytics
In the Firebase console we can track real-time user usage, Below are the main core features for tracking the user
Users in the last 30 minutes.
User's activity over time using a date picker represents inline charts.
Track the users by app version.
Track users by device Model.
User Retention.
