I'm implementing an autocomplete functionallity in a mobile app. I plan to have an autocomplete function on Parse Cloud Code but I'm afraid of the latency/delay that could bring up.
Specifically I would like to know how is calling parse Cloud Functions compared to do calls to a regular webserver over a WebSocket connection.
NOTE: I see the iOS SDK call to Parse functions uses NSURLSession which will leverage KeepAlive by default. What I don't know if the server copes up with that.
Cloud functions can be done both sync and async however they are very stingy about how long the connection stays open. In other-words you'd have to separate api calls. So, your answer is no.
Also, I might mention this from their guide on iOS cloud code calls
There is a limit of 8 concurrent httpRequests per Cloud Code request, and additional requests will be queued up.
This means that even if you somehow forced the connection to stay open like a WebSocket...you couldn't have more than 8 people using that view/cloud function at a time or everyone else wouldn't be able to access the function.
However, Ive dealt with this myself and you have a few options....
1)Make your own SocketIO server that make rest requests to parses cloud code functions. Theres even a iOS SDK from SocketIO now. So this is a pretty easy option.
2)Accept that youll have a pretty high API call rate and keep making it.
3)Do what I did and Call all the objects you need at the beginning and have iOS perform the autocomplete on the fly. Heres a helpful search on cocoa controls that should give you a head start to get it handled check it out here. Any one of these would save you hours of time of trying to sort through and repopulate yourself. If you have a lot of objects you need to get. Remember if you are returning more than 100 results(the default return amount) set query.limit = 1000(max return limit).
Related
I am currently building an app that will run on parse server on back4app. I wanted to know if there are any tips for lowering requests. I feel like my current app setup is not taking advantage of any methods to lower requests.
For example: when i call a cloud code function is that one request even if the cloud code function has multiple queries in it? Can I use cloud code to lower requests some how?
another example : If I use parse local data store rather than constantly getting data from server can that lower requests or does it not really because you would still need to update changes later on. Or do all the changes get sent at once and count as one request.
Sorry I am very new to looking at how requests and back end pricing is measured in general. I want to make sure I can be as efficient as possible in order to get my app out without going over budget.
Take a look in this link here:
http://docs.parseplatform.org/ios/guide/#performance
Most part of the tips there are useful both for performance and number of requests.
About your questions:
1) Cloud code - each call to a cloud code function counts as a single request, no matter how many queries you do
2) Client side cache - for sure it will reduce the total amount of requests you do in the server
I'd like some advice on how to implement the following in Objective C. The actual application in related to an AB testing framework I'm working on, but that context shouldn't matter too much.
I have an IOS application, and when a certain event happens I'd like to send a log message to a HTTP Service endpoint.
I don't want to send the message every time the event happens. Instead I'd prefer to aggregate them, and when it gets to some (configurable) number, I'd like to send them off async.
I'm thinking to wrap up a static NSMutableArray in a class with an add method. That method can check to see if we have reached the configurable max number, if we have, aggregate and send async.
Does objective-c offer any better constructs to store this data? Perhaps one that helps handle concurrency issues? Maybe some kind of message queue?
I've also seen some solutions with dispatching that I'm still trying to get my head around (I'm new).
If the log messages are important, keeping them in memory (array) might not suffice. If the app quits or crashes the NSArray will not persist on subsequent execution.
Instead, you should save them to a database with an 'sync' flag. You can trigger the sync module on every insert to check if the entries with sync flag set to false has reached a threshold and trigger the upload and set sync flag to true for all uploaded records of simply delete the synced records. This also helps you separate your logging module and syncing module and both of them work independently.
You will get a lot of help for syncing SQLite db or CoreData online. Check these links or simply google iOS database sync. If your requirements are not very complex, and you don't mind using third party or open source code, it is always better to go for a readily available solution instead of reinventing the wheel.
I'm trying to find a way to open up a connection to a web service and have that service send down JSON objects on an as-needed basis.
Say I request 20 profiles from a service. Instead of waiting for the service to build all 20, the service would build the first profile and throw it back down to the client until all 20 are created.
I've been using AFNetworking and would like to continue using it. Eventually I'd like to contribute this component back to the community if it requires an addition.
Anyone have any ideas on tackling something like this? Right now I have a service pushing JSON every few seconds to test with.
A couple of thoughts:
If you want to open a connection and respond to transmissions from the server, socket-based model seems to make sense. See Ray Wenderlich's How To Create A Socket Based iPhone App and Server for an example (the server-side stuff is likely to change based upon your server architecture, but it gives you an example). But AFNetworking is built on a NSURLConnection framework, not a socket framework, so if you wanted to integrate your socket classes into that framework, a non-inconsiderable amount of work would be involved.
Another, iOS-specific model is to use Apple's push notification service (see the push-related sections of the Local and Push Notification Programming Guide).
A third approach would be to stay with a pull mechanism, but if you're looking for a way to consume multiple feeds in a non-serial fashion would be to create multiple AFURLConnectionOperation (or the appropriate subclass) operations, and submit them concurrently (you may want to constraint maxConcurrentOperations on the queue to 4 or 5 as iOS can only have so many concurrent network operations). By issuing these concurrently, you mitigate many of the delays that result from network latencies. If you pursue this approach, some care might have to be taken for thread safety, but it's probably easier than the above two techniques.
This sounds like a job for a socket (or a web socket, whatever is easier).
I don't believe there is support for this in AF. This could be implemented in the NSURLConnection's didRecieveData method. This is triggered every time a piece of data is received, so you can do your parsing and messaging from that point. Unfortunately, I can't think of a very clean way to implement this.
Perhaps a better approach to this is to handle the appropriate rerequest via a pagination-style technique. You would request page 1 of profiles with 1/page, then request page 2, etc. You could then control the flow, i.e. if you want to request all in paralel or request one then the next sequentially. This would be less work to implement, and would (in my opinion) be cleaner and easier to maintain.
AFNetworking supports batching of requests with AFHTTPClient -enqueueBatchOfHTTPRequestOperations:progressBlock:completionBlock:.
You can use this method to return on each individual operation, as well as when all of the operations in the batch have finished.
I am using the Dropbox SDK on iOS, and am mirroring a remote directory locally. I understand the basic usage pattern - make a request, wait for the delegate to be called with the results.
When I have a large number of requests to perform, should I serialize them by waiting for the result before making the next call, or make all requests at once and then just wait for them each to come in? Does the Dropbox SDK handle the latter case intelligently (e.g. with an NSOperationQueue), or am I better off doing this myself?
If I am better off handling request queuing myself, should I change behavior when the user is on a wifi vs. cellular connection?
EDIT: I have seen CHBgDropboxSync and other existing solutions. My app requires more control over syncing than these provide, so I need to roll my own.
Depends on how many requests you need to make and how reliant they are on each other. With either GCD or NSOperation you can daisy-chain requests, you can issue them all at once and keep semaphores in your program, or you can make requests rely on others to complete. You're creating an asynchronous state machine, and its design will depend on whether that state machine is dynamic or static.
I'm making a program for IOS for the first time. I never had a iPhone so I don't really get how it works...
I want to make my system able to call a webservice on the background and depending in the answer show a notification.
How can I do this?
I read on the Internet that I can push notifications to the phone, however that won't solve my problem because I want my server to track the user position, so it need the user to silently tell the server it's gps coordinates.
Thank you,
GustDD
I will suggest building the app first to run in the foreground. I will assume you already understand how to use the GPS, so will not go into detail on that.
First off, you will need to write the server backend and app pretty much simultaneously. There are many choices for writing the server backend language wise. I prefer python, others ruby on rails. You want to build a REST API for the server that the iDevice can talk to with simple HTTP protocol.
You must decide on the API. You must think about what kind of data you will want to send and receive and how you will wrap the data. Also what HTTP protocols will you be using for specific requests, like GET POST etc. Furthermore, you will have to decide at what URL's on the server will it be useful to GET or POST to depending on the data you want to send or receive. I would suggest you use JSON to wrap your data. It is quite intuitive and easy to encode and decode.
Next you will have to decide how to talk to the server in iOS. There are many great third party libraries that dress up NSURLConnection or you can use NSURLConnection itself (sometimes a bit tedious). I personally like to use AFNetworking. It will do the JSON decoding and encoding for you which is a big bonus.
Finally, once you have the two communicating with how you want and with the data you want, now time to dress it up. You can allow your app to run in the background and collect GPS data and send it. You can also use the notification center to display information it gets from the server in the background.
Update to Comment
This will be extremely helpful for you with background programming. From an Android perspective, iOS is a little bit different since there is not really a direct correlation for Android services in iOS. Every little detail to put your project together is in that link.