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 9 years ago.
Improve this question
experts and friends. I have a question regarding creating a server for iPhone app. I have had experiences with HTML, server-side stuffs such as using PHP, mySQL etc.
But making an App utilizing a server is something I have not experienced with.
The ideas is as follows:
1.) A simple server that sends out responses in JSON format (I have only had experiences with parsing in Objective-C but not generating from within a server).
2.) Enabling users to create a very simple account (profile name, password, a 50 x 50 px profile picture)
3.) It is just a fun / learning project between me and my other coworker. We were hoping to do, let's say, if I am driving to work and so does he, on the same route, we were hoping to be able to see each other's locations on google map and send each other /receive message each other a short message via the server.
And we were hoping to do all this server stuffs (preferably) within xCode and in Objective-C. There are many resources for server-side stuffs on the web for Java, Python, PHP etc, but not Objective-C. And we would love to be able to do all these in Objective-C.
I was hoping to get some advice regarding the technologies needed (ex: from hardware to software requirements to the structure / architecture of the set up)
from all of you. Sample code and description would also be helpful.
Note: we are knowledgeable on how server works (sending / receiving requests, etc) and have coded already in Objective-C.
Thanks in advance.
if I am driving to work and so does he, on the same route, we were hoping to be able to see each other's locations on google map and send each other /receive message each other a short message via the server.
Your IP address will likely often change, so if you want your server to be always available, it will have to periodically update some database in a fixed location (e.g. dynamic DNS resolver).
However, note that Apple makes it possible for your app to stay in the background and receive location updates, but does not allow you to accept incoming network connections in the background.
The correct way to send a message to a constantly moving iOS device is through Apple's push services, as in this case Apple takes care of maintaining connection with the device.
So the best way to implement your app is still to go with classic client-server architecture:
server in a fixed location
if you want to send a message to the device, server sends a push notification through Apple's server
your app registers to receive push notifications so it's able to display them anywhere.
As for location, depending on whether you want your friend to be able to see you at all times, or only with your permission, you can either
register your app to wake up when location changes significantly to notify server about its location OR
implement a push notification my friend wants to see your location! and give the user the ability to send or decline sending the location.
If you're not sure about implementing servers and push services, Apple makes it relatively easy, as you can buy $500 Mac mini and install $20 OS X Server to get some pre-implemented functionality.
Related
In my research, I see this question has been asked a few times, but generally the response seems to be somewhere between "why would you do this?", "it's theoretically possible but not practical" and "yes, but there are technical issues".
I have a real world case where push messages will originate on an iphone and terminate on another iphone. The app is designed for family/couples, who can scan each other's phones to get device tokens, and store them within the app.
Most of the questions I found around this subject are pretty old and mentioned Apple's requirement to keep the APNS connection open for as long as possible, however I am not sure if this still holds with the HTTP2 interface that is now available.
Another comment is that it is difficult, but I'm not worried about that - I've written the server side for APNS and HTTP2, so it's "just" a case of rewriting it in objective C.
I realize that certificates are an issue, and might require users to update regularly to keep it working, although I wonder if there's some way to store them and just have the app update them automatically, without needing to update the whole app. No biggie either way.
So my question is, in 2018, is it possible to implement an iphone to iphone push notification and (taking into account what I said above), are there reasons not to? I could easily make a server for it, but the less third parties the message has to pass through, the better it is from a privacy/transparency perspective, hence peer to peer would be the ideal option.
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 trying to make an application, that will tell me about user location, for example i need to know when user entered the office and when he exit.
I tried geofencing with regions, but in my case it is not reliable, i dont have much experience with beacons this is why i dont know how reliable are they, also i would't place a gps locator on the user. I only want to know when he is in on his working place.
FYI not related to controlling people, only to check availability.
I would like to ask you for if there is better or an alternative solution on how to do this.
P.S: iOS app
P.P.S: i would like to know more about this, not a ready to go solution (thought it will also be nice :D)
I've been working a bit with iBeacons (it was a year ago though) and their reliability depends on the brand. An iBeacon has an UUID which you need to add to your app in order for you to listen to the correct iBeacon. Furthermore the iBeacon sends its signal using bluetooth so you need to have bluetooth running on the device with the app doing the listening.
Basically if you want to know when a user enters a room you'll need to set up an iBeacon in the room which sends a signal that the user entering the room catches using your app, and where your app in turn sends some kind of callback to a backend (or however you want to send the information).
You wrote that you want to know when a user enters/leaves his/hers workspace, and to do this with iBeacons the user either needs a unique iBeacon which sends a signal to your app, or the user needs to have your app which catches a signal from an iBeacon placed in the workspace. Furthermore the reliability in the precision of iBeacons are very bad, if there is a wall between the iBeacon and the app searching the signal the distance can easily give a faulty precision of 20m.
It doesn't sound like iBeacons are the way to go. You could of course place iBeacons around, for example, an office and have each user use your app. Your app in turn then listens on the different iBeacons and when it registers a beacon it sends data to a backend API telling that the user has entered the office.
Don't have a solution for you though, sorry :<
While the loaded term "spy" will certainly put off a lot of people, the basic idea here is a fairly common beacon use case. Tracking user location is perfectly fine provided that the user opts-in and knows what is going on.
The basic implementation is simple. Put one beacon with a location-specific identifier near each entrance. The app will monitor for detections of this beacon, and each time it is detected the app can record an event of that indicates the user entered or exited the workspace.
The main reliability problem with this approach is that the app cannot know whether each detection was an entry or an exit. A user could walk to the entrance then immediately leave. If the user did this twice separated by four hours, it would look identical to the system as a user arriving then leaving four hours later.
Solving the above problem means placing beacons throughout the building to provide near full coverage. This may not be practical.
Even with the above limitation, the technique can provide good enough data for some use cases.
If you had to open a resource from a database in a web browser on another computer, using an Apple tablet app as a remote control, how would you implement such a feature? This is basically what WhatsApp Web does, so it should be technically possible. But how would you go about it?
I'm assuming that you mean a situation where the app modifies something on the server, and the browser then updates automatically to reflect this. If you mean something like the iOS Remote app, then you may have to use another method (and you may not be able to do it from the browser).
To do this you'll have to have a server that both the iOS app and the browser are connected to. When the app does something, it updates the server, e.g. by submitting an HTTP request to a REST API. The server then updates the database.
Now you have to get the browser to update, and there are two ways of going about this. One is by polling the server periodically, using AJAX to update parts of the page dynamically without refreshing the whole page. This works, but there's a lot of overhead and it can be a drain on a laptop battery.
The better, but slightly more difficult to setup, alternative is to use WebSockets. WebSockets allow for two-way communication between server and client, and the connection stays open until one party closes it (or it times out after a long time). The client can submit information to or pull information from the server as before, but the server can also push information to the client without the client having to request it. This would typically be how games, chat clients, etc. can operate nearly in real time.
Setting this up isn't necessarily that difficult, but it's a very broad, open-ended topic that's beyond the scope of just iOS development. Beyond the iOS app and the web client, you'll also need a backend that's capable of using sockets. Node.js is a popular JavaScript-based backend for this sort of application; there are numerous others out there as well. You'll have to do your own research to determine what's right for you.
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 8 years ago.
Improve this question
I have read about what most people say that it is not possible to create iOS applications for the app store that is able to record calls as there are no public frameworks available that has this function. In this situation it means to record phone calls directly using the default phone app provided by Apple.
However, I have also came across several app store applications that records phone calls. While there are no public frameworks that that are able to record calls, I believe these applications in the app store uses VOIP (such as Viber). I know the difference between VOIP and direct call recording that VOIP delivers voice communications over Internet Protocol (IP) networks, such as the Internet.
My question is how VOIP is called from code in applications. Is VOIP called from some public frameworks since private frameworks are not allowed in the appstore?
Edited: Removed 2nd question
These apps are not recording Phone.app calls from the device. Think of it like Skype or a similar service for your computer. Although your computer cannot make calls, services can use VOIP (Voice Over IP) to send audio data to a server. The same thing is happening with these App Store apps.
A user downloads a call recording app on the App Store.
The user makes a phone call to someone from WITHIN THE APP THEY DOWNLOADED.
The app starts sending voice data to the server and THE SERVER proxies the call to the destination number. You will notice that the interface for the "end call" button and dial pad are different, this is because Phone.app is not being used.
Now that the app is just sending it's own audio data, it has access to and can record it.
The open source application, siphon, is a great example of how VOIP can be implemented using Objective-C in an iOS app.
I am a Ruby on Rails developer and I have a question about iOS development.
How do iPhone applications typically interact with a server?
For example, let's say you wish to send GPS coords from the iPhone to the server to be stored or processed. How is that typically done? Is it through a typical server API (like JSON)?
Sorry for such a basic question.
EDIT: Thanks for the answers below. Now, how about pushing data from the server to the iPhone app (without a request). How is that done?
The communication format is usually XML or JSON via HTTP call, but it depends on your data you wish to communicate between server and app. You may use socket connection.
Typically, every client and server exchange information via public API's.
in iOS, we prefer, RESTful webservices that deliver JSON. (There are other options also, but we prefer this)
I'd say that the best way to ensure delivery of data to the app from the server depends on whether you know the app is running or not. Push notification can deliver payload data, albeit in small quantities, to the app and it does not matter whether it's currently running or not. It's a big subject but thats a good start.