I am writing a messaging application for Android. Because 30% of Android users are still on 2.1, I have decided we will not use Google's C2DM system for push notifications, which requires 2.2+.
Does anyone have experience building medium to large scale services on android that require push notifications? I'm interested in things such as:
How many users can reliably be supported per server or per IP address?
How difficult is it to increase capacity as you go?
How long will it take to set the server up?
How reliably does it deliver messages?
How quickly does it deliver messages?
I know there are a few popular solutions out there such as MQTT, Deacon, Xtify and Urban Airship, but I cannot seem to find reliable data about the above topics from people who have actually implemented these solutions in capacity.
Urban Airship's blog has a couple of entries that describe how they are scaling their Android push solution for pre-2.2 devices:
C500k in Action at Urban Airship
Linux Kernel Tuning for C500K
Android Messaging: Deploying the Octobot
Think in the future, I highly recomend you take a look at the time it has taken for Android OS' to evolve on phones and study that against the cost of using other non-official solutions, mainly, the question you should ask yourself is, how long will 2.1 phones be on the market vs how much will it cost to run other solutions.
Do you want to break your easy solution for an "exception" to the rule? It really depends on what you want, I see people still developing for 1.6 and such, when IMO there is really such a small market share to attend there that its not worth breaking the easier and more useful 2.1 API.
As for designing your own push server, you are talking about a project that will probably take longer than 2.1's useful life. I mean from scratch.
I cant give you any insight on the solutions you have mentioned though.
Related
First things first, I am writing this question after researching quite a bit.
Broader View of the issue
In this day and age, we require a more reliable way to perform peer-to-peer communication, preferably using technologies like NFC.
I mean we are in the year 2018 and I cannot believe that there isn't reliable means to communicate peer-peer between and ios and an android. I am talking about offline, close proximity/range communication, which can open up a new world of possibilities for mobile apps. Many of the apps we use to communicate with other devices require one or more of internet, login, credentials/authentication, etc. I am making this effort because most of the readers/users/developers do not actually know what has changed in 2018, so if anythings changed, I would love to hear it!
Hindrances
IOS has very weak NFC support, functionality-wise..?
IOS doesn't support Android Beam.
Not enough members are bothered to fix this or are helpless.
IOS doesn't support non-ios Bluetooth connection? (Doubt it/Tried but failed)
What I need
Efficient cross platform solution for communication between two different mobile devices preferably offline.
A way to send and receive money other than Apple Pay/GPay/Samsung Pay/iMessage/AndroidMessages, such as over NFC/Bluetooth preferably offline mutually, but connected to internet independently.
A way to automatically send data when two devices (different platforms and within ios) are in close proximity, without the need to login or register or any other steps. At least a way to trigger something upon nearing one device from the other, like NFC basically.
What I have
Working android application that uses android Beam to send and receive ndef messages, which is easy to do, between two android devices. So we can make the payment happen here in this case.
Questions arise when we try to proceed with android -> ios or vice versa.
I have read a lot of related questions where the answer is outright NO. However, am not taking time to write this question to be told it's not possible. I want the crowd here on stack overflow to help me find a way to workaround this situation. I know it is a lot to ask, but I feel this invention or discovery will help man app developers stuck in this same zone. This question should be answerable by someone who is ideally in the Fintech domain, and is an IOS developer or mobile developer, with working knowledge of card emulation, secure element, ios 11+ or ios 12 development, NFC, NFC tags, etc.
Questions/Ideas:
Can we use the secure element and NFC Tag with ios 12 or ios 11+ libraries to simulate this required functionality?
Does any third-party library get close to having the ios/iphone act like a NFC writer?
Can we simulate NFC writer for ios?
Can I simulate a tag on android device, have the iphone read it(do not want the apple pay popup somehow) and then follow through the next workflow via the internet? For example, if I had a sender and receiver (payments), since android supports a lot more than ios, can I simulate something on android so that either the apple pay thinks am a terminal of sorts and pays me electronically (securely of course), or at the least can I read apple pay credentials of sorts and simulate a terminal and accept a payment from ios on android?
Something on these lines, I know its not very clear, though I am trying to be clear and simple.
Suggested by others and why it is not a great solution:
WebRTC - Needs internet
alljoyn - Need only 2 device not 2+ and no need for server or client setup.
Relay Server not quite sure is offline or works
android-ios-peer-to-peer-architecture question talks a lot about it as well!
developing-mobile-p2p-payment-apps question, which seems to be relevant has NO answer.
why-android-ios11-cannot-communicate-via-nfc question talks about React Native. I for one have looked at PhoneGap and Nativescript which just have the same level of support for ios. In short, it won't work.
Any I left out, in short no solution.
Comments:
//Due to the fact that there is no solution, I feel even more motivated to post this question. I feel we should come together as one and fight for this right. I mean usually seemingly impossible questions are answered here, so I figured you guys could take this as a challenge. The challenge would be to find a legal loophole, an ethical approach, nothing unethical of sorts. So let me know if we can arrive at any positive conclusion! Thank you for being patient.
//I have read the rules and "do not ask" section, so I would just request moderators to check if there *can* be any answer before you flag it or take it down, by which I mean we just need one correct answer, and it can come from anyone or anywhere.
I am pleased to reveal that there has been demand for this and Google has released Nearby API as early as 2016. This is the way to move forward. This is a device independent API.
Please checkout Monzo Bank's Nearby Pay
Google and others claim it works with Ios as well.
It has been around since 2-3 years, which means there should be good support and documentation, though I might be wrong.
I hope this answer paves the way for others in my position! Good Luck!
I've been looking for a way to send push notifications to Android, iOS and Windows phone devices. I've come across the Parse4cn1 library. This library uses Parse. However i saw on the Parse site that they will retire soon. I have the following questions regarding the Parse4cn1 library and the retirement of Parse.
Does the Parse4cn1 library still work after Parse's retirement?
Do i need to setup my own open source Parse server to support the push notifications and when i do this does it also support push notifications for Windows Phone? (http://blog.parse.com/announcements/parse-server-push-notifications/ says it doesn't but i'm not entirely sure.)
Kind regards,
R Visser
See this related SO question.
In any case, parse4cn1 will not support features that are not available in Parse Server. As far as I know, push is currently only supported for Android and iOS by Parse Server. So when parse4cn1 is updated, it will support those. However, I've not scheduled that update yet. Feel free to chip in if you have the time/resources to update the library and issue a pull request. I'll be glad to review and merge it.
By the way, I recently came across OneSignal which claims to offer free push notification on a wide range of platforms. I have my reservations though as they apparently sell your data and unspecified device info to third parties in return for the free push services. I'm yet to do a full evaluation so don't take my word for it. Have a look yourself and decide if it's interesting to you.
I hope this helps.
I am planning to build a web application and android app, which will manage huge numbers of notification (push notification), and can work in slow internet connection too. I need to send and get instant notifications. Number of users can be thousands or millions, application will have multiple servers (web farm), multiple database. Now I need to decide that which database will be best for this kind of application and which language should I use for programming. Please help me out. Any suggestions will be appreciated
Well, first you need to decide what your immediate needs are. Are you going to use this on a platforms that could potentially have hundreds of people accessing information at the same time? Then you need to estimate your future needs.
This will help you to decide your database system.
As per my experience i am suggesting you to use MYSQL database.
I Blindly Suggest you to Use Parse Cloud Database,as it provides SDK for All mobile Environments like Android and IOS for easy implementation and also it recently Launched a Javascript SDK to use.Its free for Trial.MultiPlatform Support and Secure
Check it out Here: https://www.parse.com/
Are you sure you going to get to thousands and millions users ? Everyone starts from scratch (read: zero users, except some friends). By this I mean, that you have to concentrate on what's the real issue within your development (growing app user base is different story):
Creation of Android app and it's lifecycle (updates, support of previous versions & etc).
Back-end. Will I also work on Back-end. Working on 2 'projects' (Android app and it's back-end) isn't easy. Not everyone is experienced enough to work on multiple assignments at the same time.
Valuate an option of using SaaS/Paas backend. Most of the have trial or free version for developer.
Third option is great. Get cheap/free web host. Store there configuration, that your Android app will download when it starts. In configuration you should declare what's the back-end and how to communicate with it. You can use any of known services like https://www.firebase.com or https://parse.com/plans or even use Google App engine free tier / AWS free tier.
About developing app for Android - if your app doesn't need any complex calculation or libraries - just write it with JavaScript. It's fast enough. Though, Java apps are always faster and easier to debug.
Good luck !
I am on the cusp of recieving a new project that involves creating a mobile app for android tablets. Is there a large difference in coding for web apps vs mobile apps. And is there any good links I can go to read up on it more? This will be in .Net by the way
Well, obviously both involve coding, so they are quite similar at this level.
But the restrictions that apply to you are quite different.
on a sever application, the size of the libraries you use don't usually make a difference, while the installation size of a mobile app is a definite issue
memory and processing power are usually are less of an issue on the server, as compared to a mobile device
each mobile platform usually has it's own UI framework with quite unique concepts (at least each interesting platform does it its own way)
the APIs are quite different (it's rare to have the same API for server applications and mobile applications)
So yes, there is quite a difference between writing a web-application and writing a native smartphone application.
Fundamentally coding is coding, but as with anything you are going to be using a different language with android and a different architecture for setting things up. I would suggest reading through the developer documents at developer.android.com and depending on how well you know java maybe do some studying on the basics of java development. www.thenewboston.com helped me a ton when I was first starting to program.
I have an application already developed and in production. It's developed in groovy, as a desktop application with its own UI, and its purpose is to screen-scrape a website to extract some information every minute, and show alerts to the user when it need to.
Now I am trying to move this application to android, so it will be available all the time the phone is up (the more alerts the user gets during the day the better). Before starting I would like to gather opinions from people with experience (haven't touched android yet):
I see the following ways to set the app in android:
just port the whole application to android/java and have it running in the background all the time, doing more or less what the app now does. To take into account.
I assume running groovy on android is out of the question. I think I saw once some reference to a project to port it to android but it was so slow it was useless. So it must be android/java
Getting the html pages every minute (or less if i decrease) and doing all the parsing etc is doable or drains to much battery? What about memory, pages to parse could be not so small is there any limit on android?
Set up a server side living in some hosting doing the screen-scraping every minute and only sending alerts to the background running android app, that would be much lighter than the previous one.
I assume there is some built-in push functionality in android apps can listen to?
What server side hosting/service would be recommended (and for what reason, cost, perf, easy of use...).
My guess would be 2, using GAE due to the affinity with android and maybe I could even use gaelyk to reause part of my groovy code...
I am targeting android 2.2.1 and up. The number of users is very small and easy to deal with so updating the android app is not a problem.
thanks
If you choose #1 you will not only drain the phones battery but also generate more traffic to the web-site you are scraping (if all users are scraping the same pages). In any case, I would go with #2. (Have you considered sending out an email or SMS instead of writing an app? Of course, this really depends on your use case...)
Regarding the server platform:
GAE and Android are both by Google but I don't see how that would help you in this case. I develop GAE apps and never came across any Android specific features for GAE. However, GAE seems like a good fit for your intended use. It is quite possible that you could get away with a free instance (depending on the amount of processing you need to do, which will depend on the number of users and scraping).
Some points you should also consider
with GAE you don't get a static IP as opposed to EC2.
if you need https: does not work with custom domains (so users will always see something like https://youapp.appspot.com)
On the plus side: you don't have to deal with adminstration and can focus on coding. I believe EC2 is a lot more involved in that respect. (At least that's why I chose GAE). The technology look-in is greater on GAE of course.
Hope this helps!
P.S.: Just to be clear, I have no experience with Android.