In my app I have to send a Lat/Long to my server and in return I get an array of Data within the range of 10-15m and I have to add the people on the map. I can achieve this by few different scenarios:
1- I can load all the Data within the range of 100m and only make a request if user searches outside this range.
2- I can use the method "startUpdatingLocation" whenever user searches for a location and when user is on that location I can call "stopUpdatingLocation". The Last location will be saved and used to send for the request.
3- Or I can keep the location updating and when user clicks on the button to make the request I can get the last lat/lang.
They might sound similar but I want to know which scenario saves less memory and data usage.
It depends on how often the users are performing searches, and if their searches are geographically close to one another. Approach #1 uses more memory because it has to store a larger array of data (which, depending on what the data looks like, probably isn't a very big deal) but it might save data usage in the long run if you have to perform less queries to your server. It depends on user behavior.
Approaches #2 and #3 don't seem to be any different in terms of data usage and memory since you are describing different ways of keeping the latitude and longitude of an user updated. This doesn't seem to be related to the data usage of your server.
Related
I am trying to develop an app that would show the location of multiple users near you on a map in real time. Me and my friend were thinking of getting the users location every 1 min, then upload their current location to a database, then update that on the map, and show it on other people's map. Now we realize that this would consume so much data and time from the user, also that would create so much calling to the database which we are trying to limit. So my question is, how would I show multiple users location on the map in real time? Think of uber or lyft and how they display the driver's location and also many other driver's location to the user. How did they accomplish that or if there is away of creating a similar thing without the strain on the user's data.
Steps to be followed -
Get location of the user not after every 1 minute or specific time but get location as per user moves. Get their location by using Significant-Change Location.
To get multiple users data - you must be storing data of other users, so get those data in background thread. Don't use main thread to get data but use main thread to display the data.
If you want store data into local database, so that if user is offline he does not looses any data.
PS: Start small scale then go for large scale. Don't think of handling data into large scale like uber at first. So start with 5 users and updating data into application every specific time( this is not for fetching user location but to showing data of users)
I have an app that will get Core Data objects from a server. The number of items may be very large. What's the best way to limit the number of items that Core Data will store so I don't use too much space on the phone? I was thinking that for ordered items, in applicationWillTerminate I could mark all but the first N items as toDelete and then delete them the next time the app starts (per this article http://inessential.com/2014/02/22/core_data_and_deleting_objects). Any thoughts?
As often happens, what strategy is good depends on how people use your data. What data is more important to keep available? What is less important?
Keeping the first N items in an ordered relationship is a simple rule, and fairly easy to implement. But whether it's good for your app depends on what that data is, how a person would use it, and whether not having the rest of the related objects is likely to matter. You don't even need a toDelete flag, you just need to know the value of N. But keep in mind that you can't rely on applicationWillTerminate actually being called, so it's a bad place to put critical code.
Other strategies might include:
Delete the oldest data as measured by the length of time since it was downloaded. Local data matches what's newest on the server.
Delete the oldest data as measured by the length of time since the user has accessed it. Local data matches what the user is interested in, while also allowing for new data from the server.
These are more complex, requiring date tracking in your persistent store. Only you can really say whether the advantages are worth that complexity.
Starting out though, a more important question is: does this even matter? How many items is "very large"? Does a "very large" number of items translate into a lot of data, or just a lot of little items?
For a steps calculator app, I am trying to store walking/running data and I am wondering what would be a good way to do that so that I can pull it up later when I need it. For eg. to show users their history of how much distance they walked.
I could think of two approaches:
Send all the location data\coordinates from client to the server and let server calculate the distance walked.
Calculate the distance in the client itself and keep updating the server in the background at regular intervals. The server in this case, would get data in distance units and not as co-ordinates.
Honestly, I would choose whichever approach would allow for the most responsiveness for the user. In my mind, your second approach would be more correct. If you're doing the calculations natively, I imagine you could deliver information to your user faster. Then, you could always sync the data to your server in the background later. Further, if there was a problem with a network connection, you could run into a data delivery problem that would result in losing users. Best of luck whichever you choose, and let us know what you decide and why.
My situation:
I have an app that needs to store 10,000 - 30,000 locations in some sort of storage method, which are then displayed on a MKMapView as individual pins. I also have a server that needs to be able to add to the database through pushing out changes.
Through grouping pins I've eliminated all issues with the MKMapView, my biggest focus is now on speed, storage and being able to add and replace the storage contents. What I'm currently doing is I have a text file of currently 1,000 locations as JSON-formatted, then they're just read as an array and sent to my custom map view (no issues there). My only issue is how I could update that text file (rather than downloading massive amounts of data), and store almost 30,000 locations.
Is this even feasible? It seems my current setup could scale pretty much perfectly, it's just this updating system that is causing me a headache.
Your current setup won't scale forever because you have to load the entire file into memory in one chunk. Eventually it will get to large to manage and will eat up to much memory. Unable to purge memory in the event of system low-memory, the system will shut your app down i.e. it won't be able to stay in the background but will have to reboot each time the user switches back to it.
To update, you will have to load in the entire file, parse the JSON, figure out how to update the resulting data structure, then write it all to file. One error anywhere in the process could corrupt the entire file.
You really need to look at using Core Data or even SQL. Core Data has a learning curve but once you master it, it makes implementing designs like your app trivial. You also get automatic scaling and efficient memory management.
A bit of backstory: I am working on an web application that requires quite a bit of time to prep / crunch data before giving it to the user to edit / manipulate. The data request task ~ 15 / 20 secs to complete and a couple secs to process. Once there, the user can manipulate vaules on the fly. Any manipulation of values will require the data to be reprocessed completely.
Update: To avoid confusion, I am only making the data call 1 time (the 15 sec hit) and then wanting to keep the results in memory so that I will not have to call it again until the user is 100% done working with it. So, the first pull will take a while, but, using Ajax, I am going to hit the in-memory data to constantly update and keep the response time to around 2 secs or so (I hope).
In order to make this efficient, I am moving the intial data into memory and using Ajax calls back to the server so that I can reduce processing time to handle the recalculation that occurs w/ this user's updates.
Here is my question, with performance in mind, what would be the best way to storing this data, assuming that only 1 user will be working w/ this data at any given moment.
Also, the user could potentially be working in this process for a few hours. When the user is working w/ the data, I will need some kind of failsafe to save the user's current data (either in a db or in a serialized binary file) should their session be interrupted in some way. In other words, I will need a solution that has an appropriate hook to allow me to dump out the memory object's data in the case that the user gets disconnected / distracted for too long.
So far, here are my musings:
Session State - Pros: Locked to one user. Has the Session End event which will meet my failsafe requirements. Cons: Slowest perf of the my current options. The Session End event is sometimes tricky to ensure it fires properly.
Caching - Pros: Good Perf. Has access to dependencies which could be a bonus later down the line but not really useful in current scope. Cons: No easy failsafe step other than a write based on time intervals. Global in scope - will have to ensure that users do not collide w/ each other's work.
Static - Pros: Best Perf. Easies to maintain as I can directly leverage my current class structures. Cons: No easy failsafe step other than a write based on time intervals. Global in scope - will have to ensure that users do not collide w/ each other's work.
Does anyone have any suggestions / comments on what I option I should choose?
Thanks!
Update: Forgot to mention, I am using VB.Net, Asp.Net, and Sql Server 2005 to perform this task.
I'll vote for secret option #4: use the database for this. If you're talking about a 20+ second turnaround time on the data, you are not going to gain anything by trying to do this in-memory, given the limitations of the options you presented. You might as well set this up in the database (give it a table of its own, or even a separate database if the requirements are that large).
I'd go with the caching method of for storing the data across any page loads. You can name the cache you want to store the data in to avoid conflicts.
For tracking user-made changes, I'd go with a more old-school approach: append to a text file each time the user makes a change and then sweep that file at intervals to save changes back to DB. If you name the files based on the user/account or some other session-unique indicator then there's no issue with conflict and the app (or some other support app, which might be a better idea in general) can sweep through all such files and update the DB even if the session is over.
The first part of this can be adjusted to stagger the write out more: save changes to Session, then write that to file at intervals, then sweep the file at larger intervals. you can tune it to performance and choose what level of possible user-change loss will be possible.
Use the Session, but don't rely on it.
Simply, let the user "name" the dataset, and make a point of actively persisting it for the user, either automatically, or through something as simple as a "save" button.
You can not rely on the session simply because it is (typically) tied to the users browser instance. If they accidentally close the browser (click the X button, their PC crashes, etc.), then they lose all of their work. Which would be nasty.
Once the user has that kind of control over the "persistent" state of the data, you can rely on the Session to keep it in memory and leverage that as a cache.
I think you've pretty much just answered your question with the pros/cons. But if you are looking for some peer validation, my vote is for the Session. Although the performance is slower (do you know by how much slower?), your processing is going to take a long time regardless. Do you think the user will know the difference between 15 seconds and 17 seconds? Both are "forever" in web terms, so go with the one that seems easiest to implement.
perhaps a bit off topic. I'd recommend putting those long processing calls in asynchronous (not to be confused with AJAX's asynchronous) pages.
Take a look at this article and ping me back if it doesn't make sense.
http://msdn.microsoft.com/en-us/magazine/cc163725.aspx
I suggest to create a copy of the data in a new database table (let's call it EDIT) as you send the initial results to the user. If performance is an issue, do this in a background thread.
As the user edits the data, update the table (also in a background thread if performance becomes an issue). If you have to use threads, you must make sure that the first thread is finished before you start updating the rows.
This allows a user to walk away, come back, even restart the browser and commit whenever she feels satisfied with the result.
One possible alternative to what the others mentioned, is to store the data on the client.
Assuming the dataset is not too large, and the code that manipulates it can be handled client side. You could store the data as an XML data island or JSON object. This data could then be manipulated/processed and handled all client side with no round trips to the server. If you need to persist this data back to the server the end resulting data could be posted via an AJAX or standard postback.
If this does not work with your requirements I'd go with just storing it on the SQL server as the other comment suggested.