I want to create an application which will be notified by server for new events. (lets say I have a shop and I need to inform all my iPhone users for my sales or something like this) Users who will download my application and run it and then put it in background wil have to be notified by this. Im quite new to iOS and Objective-C but if im not wrong this could be done via apple push notifications. Ive been reading about this and found out there are some providers that let you send this notifications. My question is, are there ways to create your own notification "center" in lets say c# and send notifications to iPhone-s by yourself, also if this could not be done are there any free providers?
and another thing. In objective-c app you have to subscribe your app to listen to that kind of events. Could you create app in phonegap or some other technologies so it will work with notifications? could you lets say embeed your app in objective-c (like web app in objective-c)
For sure you can do your own C# program that will push APNs to your clients (in fact I did that myself in many apps). What you have to understand is that the architecture of APN has 2 critical facts:
APNs are best effort, so no guarantee that they will reach every time.
APNs can not hold a lot of information with them when they reach your client (they have a limited number of bits, refer to the Apple documentation).
Due to these facts you might need to have your own server application (also could be in C#) that will handle sending the real information to the clients and will make sure that the data reached your client as well. Needless to say, this server application should sit and run on a real server. Maybe due to this fact some developers start looking for a third party solution, but personally I prefer not to use a third party and I do everything myself.
Other than having your own server application, your iPhone app will need to have some sort of database (probably SQLite3) to store the received news and display them later on.
EDIT: Answer of your questions in the comments below:
For the first question "why iPhone app must have sql db". In fact it is not a must, as I said in my answer above, it is probable or a possibility. To know if you will need a database or not this depends on the nature of your app itself. For example you might be pushing text and images to your clients and in that case you can not fit such data in the payload of the APN. Another possibility, you might want not to lose the sent notification even if the user discarded the APN message, you might want to show it again when he opens the app later on... So the nature of the app decides whether you will need a server or not.
For the second question "you said you dont need to send notification via third party", let me clarify something in my answer. As an Apple developer I don't consider Apple servers as third party. Put differently, the real APN will only be sent via Apple servers and we can not change this fact (nor do we want to change it too). So at the end of the day the real APN will be sent to Apple servers and Apple servers will work on delivering it to the actual client. What I consider a third party is someone that has his own server, you send the message you want to him, and then he sends it to Apple servers. In that case there is someone between you and the Appl APN servers and this is what I called a third party, and this third party can be avoided as your C# code can directly connect to the Apple APN servers and ask it to send the message to the client. I hope I clarified my point.
Yes, you can use APNS with the phonegap application: Receiving push notification on PhoneGap for iOS
Regarding the server, there is another option for you besides doing everything from scratch. You can use the third-party server via API, seems that pushwoosh (http://pushwoosh.com) guys offer this option (and they provide phonegap integration as well)
Related
I am writing a messaging app in Swift where people can chat similar to how text messages or other popular chat apps work. The supporting API is on AWS, written in C#.
There are some points of interest here:
Hoping to avoid third party stuff like Firebase, etc, but open to listening to advice
Alert notifications are not desired for now - no popups, banners, etc. Simply want to show message bubbles arrive in real time on one viewcontroller - if and only if the person is staring at the message screen. If they're somewhere else on the app, nothing happens.
We don't want to prompt the user to ask them if they're OK with this app sending notifications because we're not sending them banners or anything visual, aside from a new chat arriving. Is that a requirement with APNS? I feel like this means someone can say NO, and then we have no way to update the chat app in real time, which won't fly.
I assume a simple approach would be some sort of timer/loop that runs from the message viewcontroller, where every second or two it hits the API and asks if there are new messages, but that seems inherently wrong to me - the app must be robust, and there could be thousands or hundreds of thousands of people using this - that's a lot of API requests, and in many cases there could be no new messages, thus a wasted call. This is clearly not the way to go, correct?
Question # 1
I was thinking, then, that I should use APNS, however am not sure if it requires you to prompt the user to ask them for permission to receive anything from Apple? Again my concern is the chat bubbles should come in at real time and don't want to give the user the ability to somehow not see these (breaking the app)
If APNS is the way to go, and I must prompt them, then I assume the flow is I will gather my device ids (created in appdelegate, saved in my C# db, and associated to each message thread) and whenever someone types a message, it goes to my API, I save it in the message database table, and then I send out a message to APNS to everyone's device id.
Apple queues this up, and sends to everyone, and if they're on the screen, then the message comes in.
Is this how I should leverage APNS to achieve what I want?
Question # 2 I've seen others recommend using SNS (in conjunction with APNS) however I don't understand why. Doesn't APNS both act as a proper queue, as well as a notification service, thus invalidating the need to use AWS's SNS/SQS at all? It seems redundant to me but maybe I just don't understand the idea behind why you need both technologies.
Appreciate anyone's time in advance if they can shed some light on this for me!
Thanks!
Question 1
Even if you're using WebSockets (As #stevenpcurtis mentioned), you still need to inform user about the fact that user received message when application is in background/suspended. And yes, you must "force" your user to enable notifications for the application and explain why he needs it. Empirically, if user installs messenger, he understands what are notifications used for and why he enables it.
Question 2
From the mobile perspective SNS will still deliver Push notifications when user receives notification while the application is in background or suspended. From the backend perspective you can use SNS.
Conclusion:
From the mobile perspective you have 2 modes:
Application is active - it's generally up to you how to receive messages. (Web Sockets, pushes, e.t.c.)
Application is in the background or is suspended: You need a tool to inform user about changes without having a control on application. This is the job for Push Notification Service. The way you will send pushes from the backend is up to you.
You can also check This question to get some more information.
I need to implement a message service into my app that works exactly like this:
users register with a nickname within the app
they can add contacts (just nicknames) and send them a message by just specifying their nickname
they can send a message whenever they want, and the message is stored on a server until when the receiver connects to internet.
when a message is received, a push notification is triggered.
So, the messages work pretty much like emails, however instead of using email addresses, we only use usernames. I'm also going to build my own back-end for it.
Which APIs should I use or which 3rd party framework can I use ?
And any tip ?
N.B. I need to make it work with iOS 3.0 as well.
and in the future I will develop an Android app, so the nicknames should be unique and I should be able to send messages from iPhone to Android devices within the same app.
thanks
I've successfully used the Three20 library and would recommend giving it a try. It's an open source spin-off originated by the author of the Facebook app. It features a bunch of additional GUI components that might be useful to your project, like a message composer that resembles the one used by Apple's email app.
Also, Three20 features a nice framework for handling navigation within your app. Currently, the biggest drawback seems to be that certain features don't play well with the iPad API.
The answer seems to be Push Notifications
I'm looking into push notifications for an app I'm creating. I've heard lots about UrbanAirship but I can't seem to find a definitive reason why I should use it? As far as I understand it UA is a middle man? This page shows the free version doesn't have a push composer, so a developer will still need a server themselves to create the notification, if their own server is needed then I might as well go directly to APNS?
What is the point and advantage of UA? And if you use it how do you send notifications without your own server?
A working implementation of push notifications involves many things, such as:
Keeping track of Device IDs (web service for the device to contact, database to store the IDs)
Storing metadata associated with each Device ID (ie. so you can refer to a device by a username or a group of devices by a tag)
Keeping track of which devices have been deactivated (which happens if the user turns of notifications)
Clearing out bad Device IDs
Actually forming the raw request to send the message to Apple's servers
Some sort of service/program to know when you need to send the notifications
Urban Airship takes care of 1-5 for you, which greatly simplifies the whole process. Yes, you if were just sending a message to one device, you could probably find a C# or python or Objective-C library to connect to Apple and form the message but as soon as you need to keep track of a large number of devices, Urban Airship provides a service for free (if under 1 million pushes a month) to take a lot of work off your shoulders.
(And this is just for the basic push service for iPhone, as this is the only service I have used)
To answer your other question, you do still need some 'server' or program to know when to push (#6). I, for example, monitor twitter with a python program for keywords and send out notifications when I see those. My program is not concerned with the details of how to send notifications, the Urban Airship library I use takes care of the interaction with Urban Airship and Apple.
If you start your free trial at nextdns, you find urbanairship becomes one of the most common offenders that they block.
Is there any good advice on uploading files to the device? I've seen many apps create a http server on 80 or 8080 to upload files. Does that mean I have to implement a server too?
Are there any 3rd-party libraries? (Preferably open-source and non-GPL)
EDIT: I am going to upgrade files in the app for specific devices in a corporate environment, so the ipad pulling files from a central server is also an alternative. But I would have to send messages to these ipads to tell them to fetch those files.
But I would have to send messages to
these ipads to tell them to fetch
those files.
Push Notification Programming Guide
Or mail with custom URL scheme for launching your application.
iOS Application Programming Guide - Implementing Custom URL Schemes
I assume what you want is a kind of automatic update. An app do something by order from server without user's manual operation.
I don't know enterprise-license specific feature of iOS. But I believe there's no such enterprise-specific APIs. And as I know, automatic update is almost impossible. Because,
There is no system-level support for automatic update. (yet?)
So messaging and fetching feature should be implemented in app.
But no app is guaranteed to run in background for long time.
And also user can turn off any app at any time.
There is no way to send message to an app which is not running.
Even you can send, there is no way to address each client form the server.
If your app is running, sending message or commanding them to fetch or do anything is just a simple work. The problem is there is no regular way to force them always keep alive. Even under situations like OS reboot or abnormal termination.
However there is an alternative. Just registering app as VOIP app like Skype. OS does not keep the app running too, but will monitor specific socket port, and will wake your app when the socket receives some message. For more details, see here: http://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/BackgroundExecution/BackgroundExecution.html#//apple_ref/doc/uid/TP40007072-CH5-SW15
In AppStore, an app using VOIP for other purpose like automatic update will not be passed, but you have no need to concern about it.
And other way to send message to device without running app is push notification. This is a feature supported in system-level. But this is not designed to commanding app. This is designed to send textual message. So If your app is not running, the message will be displayed to user. However, you can guide the user to start the app by sending push notification.
As a final option, you can request some feature to Apple for enterprise environment. If your company is big enough to get an enterprise license, Apple will consider your feature request seriously.
If you decided to use VOIP method, I'm sorry I can't help you any more. I have no experience of implementing this kind of app. But it should not so hard.
However hard part is server. It definitely require custom server program which keeps TCP/IP connection. Regular HTTP server cannot be used. Because HTTP itself is designed as not to keep TCP/IP connection. You have to build this kind of server yourself from scratch. You'll have to handle lower level TCP/IP transmissions.
There are a few solutions(both of free/commercial) for this kind of server, but none of are popular because this kind of server regularly needs full customization. So there's nothing to re-use or share.
However I believe this is most suitable implementation for your app.
If you can satisfy automatic update only when the app is running, you can archive it by polling server status from the client periodically.
This is easy to implement because you can use regular HTTP servers for this. Client connect and download recent updates from central server periodically. If there is a new update, just fetch and do what you want. And the app is launched, just check the update at first. Prevent all operation until update applied.
This is regular way. Most of applications are built with this method. In this case, you have no need to implement server or hard thing.
However applying speed of update is depend on polling period.
(Edit)
I couldn't care about private APIs. Because your app is not for AppStore, so you can use private API's freely. (This is different thing with jail-breaking. There are so many hidden features by excluded from documentation) I don't know about private APIs, but it's possible there is some API which enable the support for keep-alive of the app.
However, this reverse engineering work is so painful unless you're born to hack.
You may try to use the following open-source in your project:
http://code.google.com/p/cocoahttpserver/
https://github.com/robin/cocoa-web-resource/wiki
Apple has some sample code on their website that details exactly what you're looking for:
http://developer.apple.com/library/mac/samplecode/CocoaHTTPServer/CocoaHTTPServer.zip
So you have a couple options:
You could distribute your app wirelessly within your organization and push new content out as app updates. Apple provides this option to their Enterprise Developers.
Wireless App Distribution
iPhone enables enterprises to securely host and wirelessly distribute in-house apps to employees over Wi-Fi and 3G. Apps can be updated without requiring users to connect to their computers. In-house apps can be hosted on any web server accessible to users. Users simply tap on a URL to install apps wirelessly without needing to connect to their computers.
The alternative is you configure the app to fetch the updated data. You describe adding an HTTP server to the iOS device, but there's no way the server can receive data when the app isn't running. Given your needs, it would probably work better to embed a web client in your app instead.
If I was in your shoes (and option #1 didn't work), I'd use ASIHTTPRequest to check with a server at launch/daily. If there are new updates, the app could then either prompt the user that there are new data files to download, or it could just silently download them in a background thread.
UPDATED: Perhaps I should have been more explicit about how to do #2. You can configure the download so it isn't interrupted when the user quits the app (you don't need to do a Voip hack). Check out the Completing a Finite Length Task in the Background section in the iOS Programming Guide.
There are http server sample codes from Apple and open source community such as cocoahttpserver TouchHTTPD.
You can upload file to the http server on iphone.
Here's a blog and screen-shots about running cocoahttpserver and upload file to iphone.
The Python CGIHTTPServer allows you to create a server in 0 lines of code:
jcomeau#intrepid:~/rentacoder/bin2txt$ python -m CGIHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...
Actually implementing a script to parse the input and save the file would take a little more effort.
[later]
OK, so forget about that, Apple doesn't allow it. See Local server on iPad for the iPad at least.
I'm doing research for making a chat based app for the iPhone (it's not really text chat in the regular sense, but the principles are the same).
Maximum 6 people can be logged into the same chat room at any one time, and the most basic question is how to efficiently check for new messages?
Would I need to simply poll the server periodically? Or is there a way I could trigger an event on the phone from the server whenever there is some new content to pay attention to?
If having to poll all the time, I worry about the resulting lag as each participant will have to wait longer for others before they can post their own responses to others. And, potentially it might also be too much to handle for the server to respond to lots of requests all the time. It would also waste bandwidth, which is not free for the user...
Unfortunately I will not be able to set up a socket server for this app, it has to be based around a regular LAMP configuration.
I think you can either go with push notifications, or XMPP (Jabber) server.
XMPP will allow your iphone app to receive data even when in the background using the new multitasking features (listening for a socket), and i'm pretty sure you should find ready to use servers for LAMP (or at least open source implementations).
Note that the iOS4 multitasking API doesn't support polling in the background, so your only other option should be push notifications. If you're new to push notifications, you can maybe use a service like Urban Airship that might make the process easier.
XMPP sounds good for you idea, i think this is the best technology for Chat. It alos works great in iOS apps.
Maybe this code sample will be helpful to start using XMPP in iOS app - look at this QuickBlox Chat code sample. It demonstrates how to integrate 1-1 Chat, Chat in room into your android application. Also there is guide how it works. I think there will be no problem to integrate it into your application. Otherwise - Comments system below allows to ask any question you want and get fast answer.
Also there is Demo video http://www.youtube.com/watch?feature=player_embedded&v=SncQaJBBW_0 how this Chat works.
In my opinion the best solution is socket, but you say that you can't implement the server side for this.
You could also implement it with push notifications. You can receive the push also when your app is running and send all the data you need inside the push. Usually chat messages are short...
If you don't want to mess with push notifications on the server then the only thing left, as long as I know, is the polling.