3 ms·
100% agree. Building my first notification-based app right now and Parse seemed like the obvious and best choice. Thing is, after a bit of thinking something fe
by rackforms 11y ago
100% agree. Building my first notification-based app right now and Parse seemed like the obvious and best choice. Thing is, after a bit of thinking something felt...off. Not with the service, but off with the idea of attaching this small little project to something so...out of my control.
I dug around the net and found a working solution I could install on my own server, and now that's exactly what I've got: The experience of doing this on my own, the flexibility to grow as needed, and the code to implement again and again without needing anyone or anything else.
Building apps these days is a massive gamble for small guys like me. We often spend dozens of hours with little to no possibility of return.
Any action I can take that reduces stress points and increase my knowledge base, (and this would have been a massive stress point) I'll take.
- geoka9 11y agoMay I ask what that solution was? :)
- rackforms 11y agoAbsolutely! Please do keep in mind no system is perfect, 100% reliability is a dream we all strive to attain, and even with Parse, I've read several reports on this very thread of instances of less than perfect reliability, iffy technical support, and so on. Anecdotal sure, but still. That said: the app sends basic notifications when in-app, user-initiated events of interest occur. The server code is PHP, based off of this fantastic little tutorial: http://www.raywenderlich.com/32963/apple-push-notification-services-in-ios-6-tutorial-part-2 http://www.raywenderlich.com/32963/apple-push-notification-s... I modified and use the code in the simplest possible way: I created the API layer using my wonderful form builder software (https://www.rackforms.com https://www.rackforms.com). Yup, it's form software flexible enough to write endpoints. Check it out : ) The app sends simple GET requests to my server, which are in turn handled by the API job. If a notification is required, the API INSERT's a record into a MySQL table called push_queue. The magic, I suppose, happens with a constantly running PHP script called push.php. This guy's monitored by a simple cron job that checks for its running status every minute. if it's down, cron automatically restarts the script. The notifications are not time-sensitive that 1 minute delays are a deal breaker, and of course any sent during that time are handled automatically when the script restarts. APN Feedback is handled by a second one-the-hour cron job, which calls a simple script called feedback.php. A touch of code was added to deal with the core user's device token being removed for "followers" of that user. Three Key Takeaways: 1. The entire server setup part took me about 5 hours, API code (which we'd need to write regardless) not withstanding. The biggest hurdle was the cron stuff, I shall never forget cron -v cron! Using a third-party service would have been almost the same time, I'd imagine. The best part is future projects will literally be counted in the minutes for start to finish notification server duties. 2. I got to use a language I adore (PHP), and learned a bunch with others I was quite new too (shell scripting, cron, etc). 3. Finally: No app is guaranteed success. I know many of these services have/had! generous free tiers, but after my first app (http://www.skipcast.net http://www.skipcast.net) and its frankly lousy performance, fool me once indeed. If, by some miracle, this new app gains traction, sure, I'll consider a third party. Until then, I'll do it my self thank you very much. In all -- a wonderful experience that I'm keen to tweak and learn more from at deployment time.
- geoka9 11y agoThanks! I'm going to need push notifications for an Android app and was thinking about using Parse. This news came as a little shock, but perfect timing!