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.
Related
I am trying to build a build a platform where in the user enters data and that data is sent to the MT4 platform. Trades are to be done based on these data. Simultaneously i need updates about the trades happening at my platform from the MT4 platform. I dont know anything about how to do it. So any help would be appreciated.
I would choose sockets as the way to do it. It requires DLL. I think the best lib can be downloaded here, or you may take that one and update a little to compress and get rid of some MQL4/5 scenarios.
Implement OnChartEvent() in your expert advisor to receive updates from the sockets.
Think of initial synchronization (some deals may be opened, and some pending orders might be placed when your EA starts - think of that scenario carefully, probably place pending orders and those market that are in red, or choose another scenario). For that, make sure your socket server (written in Python, Java or any other language that you know, you may find better examples) accepts some key word to return all the actual data, and that you keep such data.
If you need to pass some data from MT4 to your application, sockets can work too, alternative is to implement a REST service in your application and send data from MT4 using its WebRequest function.
If you need to copy trades received from the server, look for some examples of trading copiers to understand how it should work.
In a World of Warcraft Vanilla Lua Addon Development, how can I issue an HTTP call to receive data back? If not, how can I get data from a web source into the game while playing?
I have a feeling the answer is tragically short, but would like the question asked and answered on Stack Overflow. My research came up lacking, and I recall doing some LUA in ~2007 and was disappointed.
Well, tragically short is an understatement. You simply can't. There was never any APIs that interacted directly with connections, let alone create any, let alone to arbitrary URLs.
Most of them just broadcast game events that occur from the game's connection, and the closest thing you can get to a "data stream" is add-on chat channels. But since bots violate the ToS, you wouldn't be able to make an account that responds to your addon's inquiries.
The closest thing you can get is building an "asynchronous mesh network", but that's only good if your addon has a considerable user base, and it's not guaranteed you'll get information timely.
The general idea is that your addon will have a public key (as in encryption), and you (only you) will detain a private key. Your addon emits a message to any connected peers, which store it on cross-realm SavedVariables, and you hope that someone will have characters on more than one realm. Upon login, the client addon will broadcast its latest packet (still encrypted) to that realm's addon channel, and hopefully within a week or so you might get the updated information across all clients.
A disadvantage is that you'll only get "push" notifications, the client won't be able to send any data back to you*.
That, or you could release a patch for the addon on Curse :P
BUT WAIT!
You mention vanilla, so I can presume you're developing this for a private server. Private servers often have one or a very small amount of realms, making the above mesh network much simpler. Instead of a mesh, just have encryption and manually login&broadcast on each realm every time you want to update the information retrieved.
Plus, you might even be able to contact the server devs to allow you an API that sends messages to the appropriate ingame addon channel (you'd have to ask).
Of course, if you pretend to make your addon server-agnostic, instead of tailored to a specific server, you're back to square one.
* Unless you are really dedicated to make that happen, because it's a ton of work.
There is no web API in vanilla WoW. There is a web browser widget in the game currently though, albeit very limited in usage.
If you have access to the server software code, you may be able to hook listening on specific game channels for user messages in a defined format, and let the server respond in a way for the addon to parse it.
This is for a visualisation project on what data gets recorded about us from our phones.
The idea would be to log as much detail as is reasonable to an internal location (probably) on the phone for later analysis, e.g. HTTP requests. It doesn’t need to be secret at all – the subject will be aware they are participating – and it doesn’t have to be 100% automatic; if the phone owner needs to perform some action regularly that’s okay too, although they need to be able to use their phone approximately normally throughout the day.
I can’t find any Apple APIs that look suitable, but that’s hardly surprising. I can find some approaches that would potentially work on OSX (tcpdump, netstat), so perhaps a jailbroken iOS device would support one of those?
Alternatively, running a custom proxy server would open up a bunch more options, but is there any way to get a mobile device to reliably route through a proxy server?
It appears this question provides a viable proxy-server-based approach:
https://apple.stackexchange.com/questions/81102/proxy-settings-for-iphone-3g-connection
Basically, it seems it is possible to route all requests through a proxy server, even over cellular.
I am trying to make an iOS app which would involve 5 or so users connected to a single web document, with one of them editing it while the others received updates in realtime.
How can I make the app so that it can update its documents in realtime (without the user having to click a "sync" button)? It should work similar to shared google docs, when one user makes a change, it is instantly reflected in all users' copies, but it should run natively on iOS, not through a web browser.
I am not asking for a full app schematic or any code, I only need a nudge in the right direction.
I would suggest that you keep a master copy of the document on your server (and by the way, you will need a server in order to make this work effectively), and while the users edit a temporary version of the document that is stored locally on their iPhones, the server is constantly notified of changes when there is one, and when the version on the server is changed (if the version on the server isn't the same as the one on the device), the server sends a message using a special protocol that you will make to specify if
Content (text, image or something else) is added to the document
Content is removed from the document
Content is edited in the document
... You get the point
All you need are different ways to notify the devices of different types of changes made to the server document. From those notifications, the user's temporary document can get changed according to what change was made to the server's version without having to constantly download the full document over and over. Every once in a while (or from manual user input), you can have the iPhone app request the full server document to make sure that all changes made on the iPhone are correct.
Use NSInputStreams and NSOutputStreams to receive and send messages to your server. Use an NSStreamDelegate to handle server events (its only instance method is an event handling method). This guide is an excellent start if you really don't know anything about sending messages. You can send and receive NSData and NSStrings in which you can store your protocol.
As an example of protocol, an app that I have created that receives and sends messages to and from a Windows server does the following:
When preparing the data to be sent on the iOS app, I first write 4 bytes of data to an NSData object that contain the length of the proceeding data so that the server knows exactly how many bytes to read from the stream. I chose 4 bytes since that's the size of an unsigned int type, which can represent very large numbers (and therefore very large data sizes).
I add the data to the NSData object. The data is in the form of a struct in my case. Really, you can send any type of data so long as you know how to parse it at the other end.
I send the NSData object.
Really, sending, receiving and parsing NSStream messages is very simple, but if you are writing server-client code for the first time for an iOS app, the process can seem daunting. I did simplify the process down quite a bit, because you also have to consider if the server is ready to receive messages, has space available for messages to be written and so on, but the guide that I linked to earlier, which is also right here, was quite helpful as I was writing my client-server app.
Hopefully these guidelines are general enough (and specific on the right topics) for your liking.
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)