I'm currently working on an android app and I'm using firestore as my storage method. There is a feature in my app that, after a user selects a city, It downloads all it's stores. Given that those stores do not change often, I'm using a flag to know if the stores from one city had been downloaded before, so that I can use cached data instead of server data. My problem is that, if the info of a store changes, a store is added or a store is deleted, the only way the user can get the updated data is to "force download" the city again.
I would like to add a real time listener for a city instead of force downloading. The thing here is that I don't know that, for example, if I have all the stores in cache and suddenly the store "ABCD" changes and triggers my snapshot listener, will it update my cache data as well? If not, is there a way to achieve this?
Thanks!
If you don't have a listener active for the documents of interest that might change, then nothing will change in your local cache. You simply must have that listener active in order to get changes to documents as they happen, and that will cost document reads.
Consider using Firebase Cloud Messaging from your backend to tell your app when data has changed, and it can query that data as needed. That will be a fair amount of work to set up.
Related
For example I expect this kind of situation: data in my application lost relevance and so it usless until update. And until update it have to show users some predefined message.
Is here any simple and free solution to this task?
Guess I can use some server to somehow send simple messages... but it sounds way too complicated.
If this is important I use Xamarin.
Update: main difficulty here is fact - my application can't in any way define if it's outdated or not. This may happen in random moment.
Although the requirement is not very clear I assume Update here means app update.
each time user launches app make call to an api on ur server to check if user needs to update app
If that returns true take user to a static view that says app needs update and redirects user to google play to install updates
If you want to avoid using a server, you should try Firebase (https://firebase.google.com/). More specifically, you should use Firebase Remote Config (https://firebase.google.com/features/remote-config/).
Define in a key-value pair of something like minimum_app_version_required in Firebase Remote Config. Every time user opens the your app, compare the values of app version and minimum_app_version_required that you are getting from Firebase console and show a dialog box accordingly. You can also change the value of minimum_app_version_required anytime you want.
Just set some internal flag. That when that situation occurs, you can set the flag to true and just edit whatever layout element you are using such as listView or any other element with your predefined messages saved in strings.xml. You can also build any custom pop up screen, depends how you want to show them. Let me know if you didn't understand or exactly how you want?
Need to implement versioning for this problem. To achieve this, you have to maintain a version number in server, this is the version number you app will have to save and use it to validate with server. If both are not same, then app will get the latest data from the server.
I'm writing an android application that has a search feature that needs to autocomplete from a list of stores. This list will only have up to a few thousand stores in it.
My current methodology is to send a LIKE query to the database every few hundred ms after the user has stopped typing and to populate the autocomplete list with these results.
Would using this method be stressful to the database?
It has been suggested to me that this wouldn't work because making continuous calls would be poor for users with a slow connection and that I should load all the stores into memory and filter from there.
At my work I ran into a similar problem a few months back. The contents of a text box filled by the user were supposed to filter their available options to choose from in a list of strings. The list needed to be updated every time the user typed a key so database calls to fetch records that matched their text were being made several times a second.
This ended up being wayy to slow to update as someone was typing, and this was only with several thousand records and with a server that was being accessed on site.
If you want to update as quickly as someone can type, making that many database calls simply won't do. Users will get pretty antsy having to let their phone buffer to type in some text.
In Short: Make one databse call and load it up onto the phone, and run your filter algorithm from there.
Regularly syncing the list of stores from your back end to the user's device and implementing autocomplete locally is the best way to go.
The JobScheduler API provides a flexible way to set constraints on your background syncing processes.
When my app is triggered, it takes the current position of the user through the GPS (this function already implemented).
My question is: I want to know for example if I have users who are using my app in a given radius (1km for example). Is it possible?
Yes, but you need a server as well. Broadly speaking, the process is as follows:
The app gets the location from Android.
The app queries the server, sending the current location in its request.
The server stores the location and the user name in a spatial database; that is, a database of users that can be indexed by location. It overwrites the previous location if there was one. The server should also store the time the location was set.
The server also looks up the location in the spatial database to find all the users in the given radius, or the nearest n users. It sends the list of users back to the app. It might use JSON, XML, or some other format to send these data. (Since you control both the server and the app, you can choose whatever format you like.)
The app reports its position to the server again if the device's location changes, and gets a new list of users.
You can also use Google Cloud Messaging, or a persistent connection, to let the server notify the app when new users appear nearby, if your application needs that.
When the user goes offline, the app sends another message to the server to tell it. This erases the user's location for the database so this user won't show up after he has left the area.
The server should also delete locations from the database if they haven't been updated in a certain amount of time, in case the app crashed or got disconnected abruptly.
For the server, you can implement something on top of PostGIS, for example. PostGIS is a plugin for PostgreSQL that allows it to answer spatial queries.
This is a very specific need, so I don't think there's any existing code you can download to do this for you. Once you've tried it out, ask a new question if you get stuck.
I have to store value for temporary use so I used SharedPrefences for that but in this case when the user goes to Setting -> Application -> Application and then clicks on Force stop and Clear data then SharedPrefences is lost. So is there any suggest to solve this problem?
You can use element android:manageSpaceActivity in your AndroidManifest.xml to point to an activity. So when the user goes to the details page of your app in Settings, there will be a button Manage space instead of Clear data. Clicking that button will bring your specified activity up. Then you can show the user options to manage data (database, preferences…).
The only work around to fix this problem is to use a web service and store your data on the server. You can make device IMEI as primary key to avoid duplication.
as already mentioned above, the only proper way to prevent the user from having the possibility to delete your app data is storing the data on the web and download when needed. You can do both and then perform a check on runtime. If the required data is missing, then it gets downloaded
I'm looking for a way to cache as much data as possible in my app. Most of this data, are items which are crucial for the following steps, like a list of friends. Depending on the selected friend I show a list with certain items and can send something to this friend.
I would like to cache the list of friends. In such way, that it's not possible to send something to a non-existant friend, which would obviously cause an error. Or maybe the cache could work such that it shows a "invalid cached friend" message and refreshes after it...?
The list of friends will not change very frequently but still can change while the user is using the app.
I also want to cache the items which can be sent to the users. These also will not change very frequently, but it's very important that the user doesn't send non-existent items, and it's of course desirable that they see the newest items, if they were updated on the server side.
It's the same principle like caching items which can be bought, for example. It's critical that the users doon't try to complete a transaction with an invalid item.
I have already done some research, but could only come up with a rough idea so far:
Compare data using hash or timestamp: In this case I don't know at which point to do it? Loading the screen probably doesn't make any sense, since the user would have to wait for the server's response anyways. Maybe a background process? But how often do I run it? How do I synchronize?
Also, I can add an update menu item such that the user can ensure that the data is updated. But it still doesn't solve the problem that the user can try to complete transactions with invalid data (if they don't press the button).
I also found some information about "real time data" and AVIs but I think that's not applicable for my case, my data will change seldomly, but it's required that it's valid, since it's not only informative data, it's transaction determining data.
What is the way to handle this?
I think you are right, you should check the timestamp with the data source (the server).
If that's a peer-to-peer exchange between friends, just before sending your data, request its timestamp from the server. Not so much data, usually close to real time. But there's still some minor probability of sending obsolete data - just "a nanosecond" after an update.
If it's through the server (and why not?), as a bonus, you will have optimistic locking by checking the timestamp on the server and canceling the transaction if the data being sent is obsolete.