I am running a mapbox application whereby the drivers get notified when they enter a specific zone. Therefore the app is constantly chcecking to see if the user is in the zone. This causes tilequery API to increase drastically. IS there any measures or different methods I can use to reduce this? I need the app to notify users when they are in a zone.
Related
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 am a rather fresh Flutter programmer so please excuse any flaws in the questions below…
I am struggling with a structural/ architecture dilemma. Here is the background:
App rationale:
my app allows its users to check little jobs available in their area and if they find time and are in a proper location to execute the job for a remuneration,
the app uses standard REST API (not Firebase) so that the server cannot be relied on sending status change notifications to trigger re-fetching of data,
the critical elements are (1) up-to date list of jobs for a given address - other user may have already taken on a job in an address (timed refresh of list e.g. every 5 mins), and (2) the app needs to keep track of the user’s location and accordingly ask the server for jobs if the user relocates by more than 2km in less than the refresh time,
The challenge:
I guess that on the basic level the app should have the following providers: (1) auth – providing the authToken, (2) geolocation – regularly checking user’s location, (3) jobList - for particular location (fetches high level job descriptions and addresses(, (4) jobDetails – fetches exact instructions for carrying a particular job,
as you can see: (2) geolocation and (3) jobList – need to refresh programmatically (at interval or on some change of geolocation), while (1) auth, (4) jobDetails are triggered by the user.
The Big Question ;) is … what is the proper architecture for the above type of app? More specifically:
should I use services for connecting to the server API and these would in turn be used by the providers?
how to ensure programmatic refetch of jobList on timer and relocation event from geolocation?
how to continually listen to location changes to detect a relocation but not overwhelming the app with processing?
should I store the (quickly outdating) jobLIst data just in its object class or should I use settings provider or a local db or maybe there is an easy way of storing the latest JSON response not to have to build the settings provider or db mapping?
in all my call to Auth api I need to provide the deviceId - how to make it available accross the app - this is pretty static but is needed in authentication so should checking it be a part of the auth provider?
If you could comment on the above or suggest a source of relevant examples I would be really grateful.
Thanks and cheers!
Here are my thoughts:
how to continually listen to location changes to detect a relocation but not overwhelming the app with processing?
You can rely on third party to do this for you. Such as: geolocator. With this, you can specify the amount of distance the user must have moved before the package notifies you of the change in user location.
should I store the (quickly outdating) jobLIst data just in its object class or ...
Since it is likely for a job listing app to use this data often and in various places, I would prefer to use db. It would be helpful in the long run too, if you plan to have some sort of analytics done on the mobile end or to gather any insights.
in all my call to Auth api I need to provide the deviceId - how to make it available accross the app ...
When you app is initialized, you could fetch the deviceID and store it in shared_preferences. Then in auth api, you could just retrieve it before making the API call.
should I use services for connecting to the server API and these would in turn be used by the providers?
As for geo location, geolocator can update you about the change in location and you could make an API call based on that.
However, if you plan to have a timer based approach to refresh your job listing, then you must realize that your users are likely to face issues arising from your inconsistent data. If you have plans to tackle it, then this implementation here might help. But I strongly feel that server supporting push notifications or maybe a web socket approach would be ideal here.
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 the manager of an iOS application and it uses Google Places API. Right now I am limited to 100,000 requests and during our testing, one or two users could use up to 2000 requests per day (without autocomplete). This means that only about 50 to 200 people will be able to use the app per day before I run out of quota. I know I will need to fill out the uplift request form when the app launches to get more quota but I still feel that I will need a very large quota based on these test results. Can anyone help me with this issue?
Note: I do not want to launch the app until I know I will be able to get a larger quota.
First up, put your review request in sooner rather than later so I have time to review it and make sure it complies with our Terms of Service.
Secondly, how are your users burning 2k requests per day? Would caching results help you lower your request count?
I'm facing the same problem!
Is it possible to use Places library of the Google Maps Javascript API which gives the quota on each end user instead of an API key so that the quota will grow as user grows. See here
Theoretically I think it's possible to do that since it just need a webView or javascript runtime to use the library, but didn't see anyone seems to use this approach.
In my app I want to set current time.I know we can get it via device but it became user specific. If user change his device time then i am not able to find current time in my report.So is there any API which can give me current time based on location or LAT-LONG.
Please share if any one has idea about this.
Thanks All.
The WorldTimeEngine webservice offers an API that converst geolocation coordinates into local time.
Edit: there's this AskGeo web API also, it seems to be free and provide time information.