Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am fairly new to IOS programming
So I do not even know how to ask exactly
But I will explain the problem
I created an application that relies mainly to fetch data from the server sometimes the size of json is too large
Is there a way to save json on the device and not to bring, but recent data or only work to synchronize with the server
the program is objective c and i uses afnetworking
back end is ASP.net-mvc
The general way to handle this use case is, you always store the latestItemId/latestItemTimestamp in your app and every time you need to get new data, you make a call to the server with this information. In your server endpoint, you use this id/timestamp and get data after this id/timestamp.
When the app requests the api endpoint for the first time, the value of latestItemId will be 0. After getting the data every time, you keep updating it. Since you are asking the server to give data only after a specific id, you will only get the needed data (latest data)
For example your server code might look like (using EF and LINQ) (The below code is to give you an idea. I did not check for compilation errors)
public List<string> Messages(int fromId=0,int top=20)
{
var d = yourDbContext.Messages
.Where(x=>x.Id>fromId)
.OrderBy(f=>f.InsertTime)
.Take(top)
.Select(c=>c.MessageBody)
.ToList();
return d;
}
From the IOS client app side, You can keep the data(latestId) in the app memory and/or use NSUserDefaults to store it. NSUserDefaults.standardUserDefaults() method might be helpful (In Swift)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
In my application I update the user data when the user logs out or closes the application.
The problem is that when he closes the application, the OS stops all the processes of the application, so I can't do my writing on Firebase.
What I want to do instead is save this data locally on the device and when the user logs back in, do the update.
I was going to save them via User Defaults but I thought that if the user had a jaibreak phone, they could theoretically access that memory area and therefore change values.
Am I getting the wrong idea?
Thanks :)
You are right, normally the sandbox of your app is protected but a super-user can access to it and read data. In this case, one solution is to prevent app-launching on rooted or jailbroken phone. There are some libs like this one to detect jailbroken phone. Some times it better to stop the app and launch a pop-up explaining why the app can't run on this phone because of cybersec rule.
But doing that keep in mind you will lost some users.
To your primary issue, writing data when the user leaves the app, this has several well-supported solutions. This is a canonical example of what beginBackgroundTask(expirationHandler:) is for. Whenever you begin a Firebase update, call beginBackgroundTask, and whenever you finish the update, call endBackgroundTask. That will tell the OS that you're currently performing an action that could benefit from a little more time before being terminated. You should expect something on the order of 30 seconds to a minute. (It used to be more like 3 minutes, but it's been tightened in newer OS versions.) That should be plenty of time for most updates.
If you are using URLSession directly, you can also make use of background tasks. See Downloading Files in the Background for details. This can be used to send data, not just transfer files. It has the major advantage of queuing operations when currently offline, and the OS will perform the transfer when possible, even if your app is no longer running. That said, this is all more complex to implement, and likely overkill for this kind of problem.
That said, if you're storing the access token anywhere in your program (including in memory), a user who reverse engineers your app can always connect to Firebase directly and send anything they want. Whether you store it in UserDefaults, in a file, or just in memory doesn't really change that. Also, last I checked, Firebase doesn't support certificate pinning if you're using their SDK, so a user can just rewrite your packets using a proxy anyway without even jailbreaking the phone.
I think that would be better to store user's data in cloud.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am using OM2M (Eclipse) implementation of OneM2M standard. Here, they are generating a Content Instance for each telemetry data, and they use a random number to generate it's ID. Now , let's say for some reason, the device sends same telemetry data twice, then in that case, we will have duplicate entries for this telemetry data since we create a random ID of content instance.
There are two possibilities -
I can use the telemetry timestamp to generate the ID for content
instance. So that there won't be any duplicate entries.
I do nothing and store the duplicate entries, so that we can later analyze the data and capture this anomaly. And change the device configurations accordingly.
Which of the two options is possible using oneM2M?
And how does oneM2M support time-series data streams?
Thanks in advance.
The scenarios you are describing in your question acre actually two different use cases:
Either you want time series data (data that is sent independently whether it has changed in specific intervals, e.g. every minute), or
You want the latest data of your sensor, and only record the changes.
You need to decide which case you want to implement for your scenario, but it seems from your question that the second use case is what you want to implement.
What you propose in option 1) is not possible because the <contentInstance> resource type does not allow updates of an existing resource. Your only possibility with this resource is to create a new <contentInstance> every time you want to store data.
Also, you cannot provide, set or update the resourceIdentifier because it is always assigned by the CSE.
However, there are a couple of options to achieve what you want to do when you only need to store one data record per sensor. You should have a look at the <container> definition because here you can set the maximumNumberOfInstance (mni) attribute to 1. This means that the <container> always makes sure to store one instance of the data automatically (ie. it removes all the older instances). To access your data you would then not directly address the <contentInstance>, but use the <latest> virtual child resource of the <container>. When sending a RETRIEVE request to that resource you would automatically get the latest <contentInstance>, independently from its name or resource identifier.
Another possibility would be using <flexContainer>. Here, you can define you own data points and store data records without any versioning. But I am not sure whether the version of om2m you are using is fully supporting the <flexContainer> resource type.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am a beginner and I have this little debate with my friend who is a Ruby and rails developer with more than five years experience, and has worked basically for the web, and I know the information he gets is from various presentations he have been to.
So, I am learning and bulding a project in the way. This project needs to get data from other devices and also send data from the administrator devices for the other users.
I want to build this app to be able to save data if the device for some reason is offline (the user will travel, and can find himself out of signal).
My friend says that I do not need t save data into the device, or not use CoreData, that I probably need some type of cache to save the data temporarily while the device is offline.
I tell him that this is not like a weather app where you only download the data and show it to the user, I need to make changes to the data and send it back to the server, so other users see the change.
So, my question is:
Do I need to use CoreData to save data locally when the device is offline and send a request to the serve parsing JSON?
Which is the best approach?
Thank you very much for your time and knowledge!
My friend says that I do not need t save data into the device, or not use CoreData, that I probably need some type of cache to save the data temporarily while the device is offline.
Where does your friend think the cache will be located if it isn't on the device? Caching but not saving data are contradictory ideas.
Core Data can be useful as an offline cache. There are other options, including saving property list files and using SQLite directly. Which one is best depends heavily on how you'll need to use the data in the app.
Do I need to use CoreData to save data locally when the device is offline, or use CoreData to save everything and send a request to the server using parse JSON file?
Keeping in mind that we don't have a detailed description of your app,
If the server provides JSON-formatted data, then you need to parse that.
If you want to use the data offline, you need to save it on the device somehow. Whether you call this a cache or not is meaningless.
Core Data is one possible approach. It might or might not be the right one, but that's a separate question that can't be answered without a lot more information about how your app uses this data.
A common approach would be to request data from the server and save it locally. When accessing data in the app, look it up in the local copy. Keep server communication and local data access separate; if they're the same thing then you're talking to the server directly for all data and have no offline access. Keep track of local changes so you can send them back to the server.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am working on an application that is dependent on data that should be loaded from our remote servers on the application first launch. Currently I simply fetch data using few different functions and then loading the data into different object arrays. I did some research about preloading data but everything I found has specifically to do with preloading data using CoreData objects. Here are my questions:
Should I load data using CoreData objects? Is it OK to load data into arrays of custom objects?
What are the pros and cons of loading that data into arrays of custom objects?
What are the pros and cons of loading the data into CoreData objects?
How should I get the application to load the data, make sure each function has completed and the data has been loaded before the application moves on with loading the primary view?
Thank you!
Both variants of loading data to CoreData objects and into array of custom objects are ok, but mainly serves different purposes. Storing data using CoreData objects is the most common way of storing persistent data. Thus if you might have to support offline mode work of your application in future, that's the right choice. If you know for sure that your application should work only in case Internet access is available, there is no need to support data persistence and storing data into array of custom objects is absolutely enough.
Talking about data server requests chaining. You can perform synchronous calls in application:didFinishLaunchingWithOptions: method. In such case application will display launch screen while data is loading. But that's probably not the best solution because user might be confused what is happening so long period of time before application actually starts. If I were you I would rather create loading screen with some kind of progress bar that shows user that data is loading and how much data is already loaded. For chaining requests in such controller I would use ReactiveCocoa. You can find an example of how to do so by this link.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
We are re-writing our system using MVC 4.0 and web API and we are currently at a decision splitter.
Would it be more efficient / best practice to do multiple small calls to a Web API rather than one single large one for displaying data on an MVC webpage:-
ie
Multiple calls :
call 1 - returns core data about a user (user model)
call 2 - returns data regarding a users status (status model)
call 3 - returns user history ( history model)
Single call :
returns a Full ViewModel that includes all the core data about a user, his current status and a list of history items
public string UserName { get;set;}
public Status UserStatus { get;set;}
public List<history> { get;set;}
Any advice would be greatly appreciated (additional info, each one of the calls is a separate database call)
While I'm not certain this is the best place for this question (I think this may fall more into the Programmers area), I would say that it really depends on what data you need most often. If you need the whole object for every page in your app, then really is it going to save you anything to make multiple small calls? If some of that data can be cached on the client side, then maybe a lot of small calls would be more efficient, but otherwise, you're increasing the amount of client (client has to retrieve, parse, and then output three streams of data) and server (where the call has to be routed, data retrieved, and data returned) work for little benefit.
Secondly, as #Damien_The_Unbeliever points out, there's the question of outsiders calling this API. If the API is public, or called by multiple apps, it's a question of what is the most efficient package that /most/ apps will need, not just what this app needs. If /most/ apps will need the whole object, then it doesn't make sense to give them calls to retrieve only pieces of that object. If they only need, say, Status, then an API method for just retrieving Status is a good call.
When you are designing an API action always think about performance, how many times in a second your action will be consumed, does your separate operation is taking too long to respond. Make simple benchmarks for each operation by using Stopwatch, then make several parallel calls to see if any operation makes bottleneck.
In my opinion every action should be simple and atomic.