I am trying to build a basic fitness app using flutter.
The app has two main features:
Daily steps counter
graph of historical data (number of steps each day)
I use the pedometer plugin to retrieve data from the sensors of the phone.
My problem is that the plugin can only send the continuous step counting since the last reboot
that means if the user does not open my app for serval days, I don't know how many steps he walked each day only the total number of steps he did. I thought about letting my app run in the background but it will be a waste of battery
P.s I read Implementing pedometer in flutter article by Masky, but it is not solving my problem.
Thanks for any kind of help :)
Excerpt from: https://hub.packtpub.com/step-detector-and-step-counters-sensors/
The event timestamp represents the time at which the last step was taken. This sensor is especially useful for those applications that don’t want to run in the background and maintain the history of steps themselves. This sensor works in batches and in continuous mode.
Of the returned SensorEvent, the 1st value represents the number of steps since the last boot and it also contains a timestamp which is the amount of nanoseconds elapsed from the time of last device boot.
This site advises to use JobScheduler to "schedule periodic job to retrieve the total step count under suitable interval."
On the first site it explains how to maintain step history in case that's what you want, there's also sample code there.
Related
I'm developing an application in Flutter for online queries and right now I'm lost as to how to show the user, for example, a message based on the exact time he previously chose. The user can already choose the day, month, year and time, and after he selects them, I can store them as Strings, but I don't know of any tool that can perform some function at that exact moment. What I want to do is that after entering the information of the day and time of the consultation, a notification appears to the user asking him if he wants to join the video call, but only at the time he chose.
I tried to calculate the difference between the chosen date and the current moment, and based on that duration I used the Timer to execute some task after the elapsed time. But I was also in doubt if this function would be executed even if the user had not opened the application, so I don't know if it would really work or not. Previously I also researched dependencies that could help, I found for example the sf_calendar, but from what I observed it only has a system to choose the date and save and display this data on the screen, but it does not allow performing some function on that date.
Can Firebase get accurate time for offline records which have been stored in device when the device's clock has been changed? The device's clock might be changed when the user rebooted the device or when the user adjusts the date time manually.
My case is quite similar to Get actual DateTime of a device in Offline Mode which I can quote here 1) The application can work in online as well as offline. The app has a feature to create and save the NOTES inside the application. Also, When the app gets internet connection, I need to send the NOTES to backend server. I have a field called 'DATECREATED' in each NOTE (the datetime where the actual NOTE was created) ISSUE: If the User has set the DateTime wrongly in the device, My application sends the incorrect DATETIME to server.
I am going to handle the offline issue on Android and IOS platform, so I came out with another possible solution such as get the GPS time, using some sort of background counter, etc. Based on my experiment, the solution are not reliable enough and some might difficult to do. That's why I decided to get the accurate timestamp using Firebase.
I read a reference https://firebase.google.com/docs/database/flutter/offline-capabilities#clock_skew, but I am not quite sure whether it can help me to get accurate time for offline records.
There is no way you can get a server timestamp while offline. Why? Simply because the timestamp is totally generated on the server. And since you're offline and cannot communicate with the server, you cannot get an estimation. So there is no other system that can generate a timestamp other than the Firebase server.
Besides that, a date that can be generated on the client can be manipulated, so you cannot rely on that.
The option that you have in my opinion would be to have two fields. One is for the real timestamp, which you'll be received when you're back online and the other one is what the client provides. In that way, you make a comparison, if this is what you want.
Edit:
Firestore, is a Cloud hosted NoSQL database. So there is no way you can generate an accurate time while the user is offline. What you can certainly do is calculate the period of time while the user is offline. This means that you have to calculate the number of minutes the user has lost connectivity. Let's say a user losses connectivity for 10 minutes, when it regains connectivity, you receive the Firestore timestamp. Now, all you have to do is to subtract those 10 minutes from the received timestamp in order to have the accurate time that you're looking for.
I have a Google smart home app released that supports various light bulb brands. I have a user with 5 Phillip Hue light bulbs and there are approximately 1360 query state requests per day for the 5 bulbs. Is this frequency of query requests common and expected for all devices?
That's one query request every ~5 minutes.
https://developers.google.com/actions/smarthome/develop/process-intents#QUERY
It is normal for Google to periodically send QUERY intents to your service to ensure that the data in Home Graph is up to date. You can mitigate this process by making sure that you have implemented Report State to publish all relevant state changes to Google in real time, as this also directly updates the state in Home Graph.
The actual frequency is a bit more difficult to pin down as it relates to not only how often you report state for devices, but also user activity on those devices. Generally speaking, the more often you report state to Google the less you should see QUERY polling.
We are also actively working on ways to reduce the need for QUERY polling, so in the future you should see the frequency of this reduced so long as you have Report State implemented for all your users' devices.
I am building a simple booking system on google calendar. However, users feel complicated, so I made a google form as a front end to simplify the data entry.
The process is straight forward. It's just form, sheets and then apps script. There is no functional problem.
There is performance issue.
The total time from Form submit to calendar update shown on browser takes in average 30 seconds. The time stamp on execution script shown less than one second to complete the apps script but it take more than ten second to start apps script. It means there is more than ten seconds for google form and sheets to complete and more than ten seconds for calendar to sync.
Any advice to shorten total processing time?
Thanks in advance,
Regards,
Thomason
I've used Fabric for quite a few applications, however I was curious about the performance when a single application submits potentially hundreds of events per minute.
For this example I'm going to be using a Pedometer application, in which I would want to keep track of the amount of steps users are taking in my application. Considering the average user walks 100 steps per minute, I wouldn't want the application to be sending several dozen updates to the server.
How would Fabric handle this, would it just tell the server "Hey, there were 273 step events in the last 5 minutes with this meta deta" or would it sent 273 step events.
Pedometer applications typically run in the background so how would we get data to Fabric without the user opening the application
Great question! Todd from Fabric. These get batched and sent at time intervals and also certain events (like installs) trigger an upload of the queued events data. You can watch our traffic in Xcode debugger if you are curious about the specifics for your app.