Let's say I want to build a SDK that communicates with a server. I don't want any one (not even the app that implements the SDK) to intercept and look at my requests/responses.
If I'd use a common lib like AFNetworking it would be possible to look at all requests i.e by registering a NSURLProtocol.
I'm assuming that this would be harder to do if I would use i.e CFNetworking to perform my request/response handling? Or am I missing something? Would it be possible to intercept that traffic as well?
Using non NSURLConnection based classes, especially C low level classes (because NSIn/OutStream can be swizzled) like CFNetwork's CFStream, would make life harder for a potential curious developer. However, it will never stop a determined one. Your framework could, for example, be decompiled, although that's not a trivial task, which means many will quit even before starting, if the information is not worthwhile.
Related
I'm developing a framework for iOS apps that allows interfacing with custom BLE devices made by my company. We're planning to distribute the framework binary with public headers to clients. I've already designed the client facing interface, but it's lacking a major feature: notification on various different status conditions. That is, when the framework starts scanning for devices, connects to a device, reads data, uploads to our backend, etc, there is currently no way for client apps to know.
This has been fine for local testing, but before releasing, it would be best to add some functionality to allow clients to build a UI that updates based on these various status conditions. I'm not entirely sure of what the current, best way to do this is. I'm aware I can create an NSNotificationCenter and post notifications for each of these status changes, but I'm not sure if there is some better way of doing this? Should I accept a user callback? Expose some sort of listener protocol and ability register listeners? I'm sure others have solved this problem before, what have you found works well for iOS?
Use NSNotificationCenter for one to many communication, it notifies all the objects, which register to event, without knowing who throws it.
Use protocol and delegates for one to one object communication.
As per my experience you should go with delegates, it will be clean implementation and you can also define optional and required protocol.The the global class on client side can use this delegates, and update.
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.
I'm developing an application that processes a real time data feed across the internet. There are 2 fundamentally different things I want to do with it: one extremely simple but critical that it never is interrupted. Another much more complex but interruption is not such a horrible problem. Given that the second would have higher risk of the application crashing due to its complexity... I'm asking if there is some way that both can be receiving the data feed at the same time?
I could have both functions in a single application but if it crashes, that's very bad. I was thinking by separating the two functions into two applications, it might provide more robust handling for the critical simple processing.
But if I separate into two applications, is it possible for both of them to receive the identical data at the same time? Some type of OS networking voodoo or something?
It depends on the stream and on the way you want to implement it - some general ideas to achieve what you describe:
make a receiver app
this has the only purpose in receiving the feed and dispatching it to any apps/consumers who register to receive... if the receiving apps are on the same system you can use shared memory (MemoryMappedFile in .NET for example) which is really fast... this would help regarding future requirements - for example if you need to implement another processing app it just needs to register with the receiver app... another nice side-effect: the receiver app can capture the feed to some persistence and thus allow a "replay" for testing purposes etc.
make the "critical" one multiplex the feed
this would mean only your critical app receives the feed and sends a copy to the other app (for example on a different thread)