I'd like to have something in my app that is just like Twitter but not Twitter. Basically it will be a place people can submit messages and do not need an account. They only way they can submit is through the app. I want other app users to see the submitted messages nearly immediate. I believe push notification can do that sort of work but do I need push notification for this? How does Twitter do it?
-- EDIT --
After reading some of the responses, push might be what I need. People will be submitting messages to my server often. If someone is watching the feed, they might see one new message per minute depending on the query they are using. I'm thinking to go with a MySQL database, (which allows switching to cheaper non Windows servers w/o much hassle) and push notification. Are there any reasons those won't work for my scenario?
You only need push notification if you want the app to be able to receive new messages while closed.
Here's a rough description of one way to do this:
Your app sends a message via HTTP Post to your server.
Your server stores the message in a database, using the iPhones unique ID as an identifier.
Your app connects to the server frequently, asking for new messages.
If there are any new ones, the server hands the message to the app, which displays it.
This is approximately what twitter/iphone twitter apps do.
Your choices are fairly binary:
Use push notification
Use Polling
With Push Notification:
You control when you contact your users... Heavy Load means you can slow updates down to avoid taxing your infrastructure
Contrariwise, you have to push to clients that may not even be there anymore (And thus may need some sort of register model), high load may mean that clients don't get immediate update
You can leverage things like Amazon's EC2 to give you more processing power
Unless you're out of capacity, users are almost certain to be receiving updates as they happen
To pick up messages missed while offline, the SERVER needs to know what message was last successfully received, store older messages and forward many all at once
If you choose to use polling:
You must have a stable address to be polled
You need the ability to have lots of quick query connections checking for new data, then returning that data if required.
If your application becomes popular enough you may find you don't have enough resources
If your resources are taxed your application will go down, rather then just slow down
You don't need to register clients and keep track of their on/offline state
Parallelizing on the fly is a bit trickier
To pick up older messages, the CLIENT needs to know when they last received a message and then request the server send any message since that time
Both can be fast, but they come with different bandwidth and processing profiles. I prefer push for everything that's real-time.
Might want to take a look at XMPP.
Twitter doesn't really push events out to the iPhone in realtime. It's more like polling by the various clients.
If you really want instantaneous for the last mile you'll want to use push.
Twitter uses lots of servers and raid arrays to handle the load of millions of people posting 140 character messages. Twitter clients log in and request a list of updates for all of the people the user is following within a certain time frame.
Push wouldn't be a good candidate for this because it does not persist the "tweets". It is simply a notification mechanism. There is a text messaging app on the App Store (called Ping!) that relies completely on push notification for sending text messages. This seems to work fine, but if the developers are keeping track of the messages, it is all done on their servers. In their case push makes sense as you want to alert the user of a new message. In the case of a twitter clone, however, it would probably just annoy users if they got a new notification every time someone tweeted.
In the end you're better off just implementing it server side and then developing an iPhone client that logs in and retrieves the latest tweets for the people the user is following.
Related
I have 2 closed-source application that must share the same data at some point. Both uses REST APIs.
An actual example are helpdesk tickets, they can be created on both applications and i need to update the data on one application when the user adds a new ticket/closes a ticket on the other application and vice versa.
Since is closed-source I can't really modify che code.
I was thinking I can create a third application that every 5 minutes or so, list both applications' tickets for differences on the precedent call, and if the data is different from the precedent call it updates the other application too.
Is there a better way of doing this?
With closed-source applications it's nearly impossible to get something out of them, unless they have some plugin-based setup that you can hook into.
The most efficient way in terms of costs would be to have the first application publish a message on a queue, or call a web-hook that you set, whenever the event is triggered. But as I mentioned, the application needs to support that.
So yeah, your solution is pretty much everything you can do for now, but keep in mind the challenges that you may encounter over time:
What if the results of both APIs are too large to be compared directly? Maybe you need to think about paging the results.
What if your app crashes and you loose the previous state? You need to somehow back it up in an external source
How often you should poll the API to make sure you're getting the updates you need, while keeping a good performance for the existing traffic?
I think I must be missing something. I have an app that loads table reservations on an iPad and in order to stay up to date, I refresh the main-page-ist every 15 seconds.
Instead I want to refresh the page only when there is a change. I want it to work like a push notification that tells my app that there has to be a change and that it needs to connect to the server and update, but some users are turning push notification off and i have no control over that. There must be a better solution I'm missing right here.
How are messaging apps doing this. How do viber, whatsApp facebook messengers know that there is a new message and show it immediately. I don't think they connect to the server every seconds... or do they?
I think, Silent Push Notification is the best solution for your case.
You can still catch the information in the background even user does not permit push notifications.
What you are doing is common but not advisable these days. You want to push, not pull. What do I mean? How often someone reserves a new table is random, so it could be 5 seconds or every 5 hours. In your case, if you refresh every 15 seconds it could be killing the battery and gobbling up data unnecessarily.
The better way is for you to set up a push server that, when a table is booked, your push server sends a push notification to your app. This way, whether instead of asking all the time "hey, any reservations?" your server tells you when a booking event happens.
Of course this requires more work on your part, but you will run into the same issue over and over again, so it's worth looking into how to do this.
If you're at a larger company, and only doing front end, you need to have the backend engineers build a push server for you.
This is how What's app and other apps notify you when you have a message.
This will be my first iOS app with any bit of complexity. I'd like to outline the components and structure to get some feedback before I dive into attempting it.
From the user's perspective, the app monitors the water level of a local lake and receives push notifications when the water level changes a user-specified amount. I think using Parse will be easiest to manage user data and I will attempt a Node.js server-side component on Nodester (I know some basic JS and figure its an good up and coming language to get familiar with). Here's how I see it working...
The user creates an account on the device and specifies a lakeLevelChange amount in which they will receive a push notification. The user's data is pushed to Parse's data mgt.
The server side component will run this program 3-6 times a day:
Pulls a currentLakeLevel via HTTP request
Pulls user data from Parse
Compares the currentLakeLevel to the user specified lakeLevelChange
If the difference is => lakeLevelChange, a push notification HTTP Post request is sent, per user which their specified condition is met
Parse receives POST request and sends a push notification to APNS server
Client receives push notification
It actually doesn't sound terribly complex when its typed out. Is this the proper way of structuring this functionality? Am I missing anything? Suggestions are greatly appreciated!
Bit of a logic problem:
The server side component will run this program 3-6 times a day:
Pulls a currentLakeLevel via HTTP request.
Pulls user data from Parse
Compares the currentLakeLevel to the user specified lakeLevelChange
If the difference is => lakeLevelChange, a push notification HTTP Post request is sent, per user which their specified condition is met
You actually need to store the level at last alert for each user, too. Otherwise incremental changes could creep over your users' threshhold and never trigger an alert.
Imagine if I said I want to be alerted when the level has changed by 6 inches. You then record seven events in which the level rises by an inch each time. At no point did you observe more than 6 inches of change, but the total change is over my threshold for notification, and I probably meant to have you notify me about that.
So when you fire an alert, you need to store the current level, and then on each change event, you compare that to the last level you notified them about.
You're missing the unhappy path. It's the path programmers never travel while programs always travel. Nothing goes the way we plan it so we have to plan for failures. Ask yourself questions like, "What happens when the server powers down for maintenance or outages and misses one or all of its 3-6 scheduled runs?" "Should the missed executions queue up and send out a bunch of missed notifications?" "What happens when the user changes what they specified as lakeLevelChange but the radio is out and/or the server request cannot complete?" "What happens when Parse gets garbage data in or produces garbage date?" Asking just a few of these will steer you towards an optimal design.
I'm currently working on an app sending request on a server for a voting system. The problem is that people can vote without registration but I don't want them to vote multiple time and I don't know how to secure this. I thought about a key system (generated in the app and verified on the server), but I'm not sure that this is the best solution.
What should I do ?
There are two possible solutions to this.
1) Handle the code that detects the duplicate vote on the server
For each vote cast the server stores the device id against the identifier of the vote. The server ignores any duplicate votes cast for that topic and sends back a "failure" response. This is handled by the device.
Pros: Centralized voting logic. Change it once on the server and all versions of apps in the wild conform.
Cons: You have to build the server logic. If you're more comfortable with ObjectiveC this may be an issue. You have to maintain the database of voting topics and devices that have voted.
2) Handle the code that detects the duplicate vote on the device
The device downloads a list of all the voting topics then filters them by the topics that have already been voted on. When a user votes on a topic then the device adds the id of that topic to the filter list.
Pros: No database maintenance beyond having a list of voting topics.
Cons: Users could remove the app, reinstall and vote again. If you want to change the voting logic (e.g. you want people to be able to vote twice on a topic) you have to update all the existing apps.
Admittedly putting the voting logic in the app makes the app more complex. However that added complexity has to be absorbed somewhere - either in the app or on the server.
I would like to create a service that parses data from a feed and then sends notifications to subscribed units.
And I'm note sure how to approach this problem. Would be thankful for any advice.
If you're going to be sending less than 1,000,000 push messages per month (greater than that amount you would have to pay), I'd look into UrbanAirship . They have something called a feed feature that does this:
Urban Airship has a feature where we
will monitor an RSS or Atom feed and
send a push notification when a new
entry is published. We allow you to
set up a template to extract items
from the feed to dynamically generate
push notifications with content from
the new entry. You can easily set this
up from the interface at
https://go.urbanairship.com/ , but
this API allows you to
programmatically create them.
So, that might work for you. Or, you can look into setting up your own server that runs a script, parsing your feeds. Then you can use Easy APNs to send the messages yourself. I'm using it and it works perfectly for my needs. For me the learning cure was steep because I'd never done anything besides Obj-C, but it ended up being quite easy to learn.