I'm developing an Android game, and now I'm in the stage where I want to create a multiplayer option.
My task it to pass between two users on different phones an integer.
My thought is to do it via facebook, to enjoy all the social benefits of it.
Do you know what API's\technologies I need to use?
I installed the facebook SDK, but cant find the specific API's to do it.
Thanks Allot, Vlady.
If the two users play against each other (or with each other) then the best approach would be a P2P connection, that it the two devices should have a socket between them for passing messages.
If that's not possible for some reason, then the fallback would be to have a central server to which all clients are connected, this server will then route the message from user A to user B.
As for the facebook option, what's the point?
It's not what their api is for.
You can use the Achievements to publish user scores and such, gain more engagement and virality, but that's not for the communication between the clients.
Related
I have been searching for a proper answer to this question, have a bit of background in front end development, but with new concepts like SaaS, PaaS, etc. want to get information from experts out there, that could help any newbie to understand what it's all about.
Say I am trying to develop eBay like an app that takes a product from a user and sells it back to the other user who needs it.
Will my app need a backend server? If so why? I am already uploading my app to Google Play Store or Apple Store.
How will the backend server like HEROKU or FIREBASE or AWS help my app?
Can I implement two different services in single app, say for eg., firebase for backend database and HEROKU for payment processing?
Thanks again for your time and information.
SaaS
Answer: SaaS stands for "Software as a Service". In layman's terms, someone developed some software and hosted it somewhere. You can use that hosted software in your software project/product as a third party service (like public API); or directly use that as individual software under some license like Firebase as mentioned.
PaaS
Answer PaaS stands for "Platform as a Service". In layman's terms, someone configured some hardware and exposed the hardware controls via some web based application or REST APIs. You can use that hardware to deploy/run/manage your application without having the actual hardware on premises.
Backend Server
Answer First of all, let me explain the server. The server is a middle-man who serves whatever is requested of it, and all browsers/mobile apps act as client. So for example, the web is all about client-server communication.
So taking the example you mentioned, an eBay-like app takes a product from a user (client action) and puts it on the server (client requests in background for server to put product on server). Then another user opens the app (client action) and searches for the product (mobile client requests server to return that product, if valid and matching search criteria), and then he can buy it (mobile client will request server to complete the purchase).
You have to understand that for any communication between web application, mobile application or desktop application, there will always be a server. Even in file sharing applications like shareit, one mobile app works as server and same mobile app elsewhere works as client.
Yes, backend servers like Heroku or Firebase or AWS will help your app to complete your application business flow.
Yes, you can implement two different services in single app, say for example, Firebase for backend database and Heroku for payment processing or hosting your application/APIs.
Unless you are experienced with building distributed applications that can persist data across multiple nodes in a consistent manner, and ensure data available, I'd say you most definitely need some kind of backend. Unless of course you only plan to have user-to-user transactions, that can rely on direct messaging between client applications - which seems pretty pointless and quite far from the requirements of an EBAY-like product.
In terms of the architecture, you can follow many different approaches, but in most of them you will require some sort of data access layer. I'd recommend looking into the three-tier software design pattern (https://en.wikipedia.org/wiki/Multitier_architecture) to better understand the way this type of software product is typically designed.
After sorting out which type of data persistence you prefer, you'll need to setup the backend where your mobile app will connect to retrieve the data from (things like products being sold, user profiles and ratings, your own history). Of course you could also connect directly to the database from the app, but that would be a big mistake - it would meaning making the DB access publicly available, and thus exposed to attack, not to mention that you would be hard-pressed to find a solution for user registration and authentication, which would have to be provided by other means anyway. Typically your backend will also manage user registration and authorisation.
Heroku, Firebase and AWS are all very different, each with their strengths and weaknesses, but there's nothing like trying them out to see what fits best. What you refer to as "Google Server" and "Apple Server" sounds like a misconception, and you probably mean the Google Play Store and the Apple Store. These are not applicational servers that you can use as a backend, and serve only as a repository for your mobile app from where users can download it, and nothing else.
Without some sort of backend mechanism, the challenge of making data available for the consumption of multiple users would be overwhelming.
I know this isn't a very specific answer, but your question is quite broad-reaching, and it seems you need to look into some basic fundaments of software engineering before going into more detail.
I am studying the feasibility of developing a mobile application for Android, for traders, where the client-side installs on a smartphone (A) and of course, through Google Play, and server-side installs itself in another smartphone (B) that installs via the Play also.
B through the merchant takes pictures of your items and upload adding a description (this article) for the application server side, in ways that the user A, which has the side application client can enjoy the products.
In short:
Capturing data to the server must be made through an Android phone that can take pictures of products and upload to the system and adding text to describe the product.
Consultation of products will be made by a mobile phone with Android as well.
Is it possible to do this? If not, I would appreciate to give me suggestions on how to do this. But I wanted to try not to make using computers (PC / Mac) or web app to load the data to the application. I want a system purely mobile. Maybe will use the computers to store the BD system only.
When you say the server side is a phone app, you imply that the phone is always on, the app is always running, and you need no central storage whatsoever.
You also lose any ability to keep analytics for your service, which is a crucial part of any startup.
If you want your app to have the server available even 80% of the time, and you want to keep a central database of what's going on, you must have some server you can control.
There are a lot of very cheap and manageable cloud solutions, so you don't need to buy an actual server.
I have two separate APK's on Google Play. I'm planning a new version of each of them that has a new in-app purchase.
I want each of my two apps to be able to query the other one to see if the item was already purchased in the other app, so the user will not have to buy the item in both apps if they have both apps installed.
I have already released both apps and they do not have a shared ID, so I don't think that's an option, because I don't think you can change the sharedID on a published app. Also, it is possible that the user installs/uninstalls these apps in various orders, or downloads them on another device, so it is not adequate to simply make a Broadcast at the time of purchase.
Is there a way to query another app for a simple boolean response?
Is there a way to query another app for a simple boolean response?
I affraid not.
most close to it would be sharing preferences across packages, but its not officially supported, and I wouldn't count on it to work across all platforms.
or MODE_WORLD_READABLE preferences, but as mentioned in the answer - it's not secure, and it anyway deprecated in API 17.
only 3 ways supported with android API to communicate between different apps are:
Accessing ContentProvider
sending and receiving BroadcastReceiver
remote Service binding
I think that you can achieve easily your goal with any one of the three, although you right when you say that sending broadcast from one to another is not the safest way.
if I had to implement such feature - I would create a simple ContentProvider from one of the two apps, and access it from both apps to store and retrieve this shared information/data.
another good approach, would be doing some server side verification to get this information. of - course it limitations are that you need to have one, and you have your users to be connected to network for that..
I would like to create an Android application that neeeds to communicate with same application at a different device from different users. The user will be logged into the application using his Google+ account and he will be able to exchange messages with his friends. Imagine it like a chat application without a server in the middle.
The problem is that I don't own a server so the communication must be based to any Google framework or it must be implemented from device to device.
Do you have any suggestions?
I don't believe its possible to connect two devices over the internet without a server somewhere in the middle, basically there is no practical way for the devices to find each other without some known location they can both contact.
Your server wouldn't need to be too complex/expensive for testing usage. The free tier of Google Apps Engine, or a $5 PHP hosting account should do it.
I have developed a simple two player chess game in android to be played using Bluetooth. I want to extend it by making it possible to be played through internet. whenever a player makes a move, the move should be transferred to the other player via internet.
How to make this possible?
I have heard of C2DM mechanism.Does that suites the scenario i described and is it reliable?
Thanks:)
Yes, C2DM is ideally suited to this type of game. This is what I am using for my own game (http://www.chesspresso.net) which is a correspondence chess client for android.
Things to consider when using C2DM:
You don't send the info to the devices, you notify the devices that a move has been made. You don't use C2DM to transfer data, you use it to notify that something has changed.
Its available for 2.2+ Android, which is the majority of devices. But if you wanted to support older devices you'd have to consider an alternative. I am using polling for older devices.
You have to request for developer access, then once your app is ready you have to request production status. If you don't do this you'll hit the developer status quota very quickly once its released! They are very generous with production quota, but you have to explain what you're using it for and it also can take a few weeks to get accepted!
Your users will have to have a google account that is authorised, otherswise C2DM won't work. Most users will have an account associated with their device, but some don't so this means that you'll possibly want to validate for the presence of an account to notify the user.
Its reliable, but every now and again a device will have to wait for the message. Sometimes a few minutes. Usually its instant.
Hope that helps!
UPDATE:
C2DM has now been deprecated, and replaced by Google's GCM.
Also, I strongly suggest looking at other options as tying yourself down to a Google specific API means you won't be able to support external marketplaces. For alternatives, I am currently evaluating Amazon SNS and I will also be looking at Urban Airship. There are possibly other alternatives I have not considered evaluating yet.
UPDATE:
Evaluation update of non google based push notifications:
Amazon SNS is just not a project for this task and Urban Airship for the vast majority of apps is too expensive. Unfortunately all the other alternatives are all very expensive also, especially if your app (like mine) relies heavily on push.
A good way of doing that is using a simple direct TCP connection between the peers.
If you're new to socket programming on Java, try this:
All About Sockets
Another option is to use some sort of IM as a communication medium for app. For eg. Use Asmack to connect to XMPP Im like GTalk. Prompt user to create an account there, for your game.
And use it to send and receive commands via IM. This way you won't need to setup your mediating server.
This works if user knows who he is playing with. To collect the user data and let them search for available players, you still need to setup a server. IRC chat room may be an option to avoid this also.
GTalk was just an example. You can use any IM or IRC also.
C2DM it's not design to transfer informations, even if they are small like "horse in b4" or things like this. It's designed to inform the device of something, maybe a newer version of a document or more articles on a website.. Stuff like this.. It's not designed to communicate device to device. And also it may be not fast enough for a real time chess play.
You should look for a more traditional way of communicate via internet or to search for some libraries (I'm pretty sure that something exists..) that will help you.
IMHO, C2DM is exactly the kind of thing you would want for a chess game; to be notified when the oppo has made his turn (which may be minutes /hours / days later ?). I have discussed my game with a few google android devs and they've stated that C2DM is ideal for this. You'll need to go via a centralised server though (well, not essential but very advisable) as there may be issues with resync'ing game state etc. Worried about "hitting the limit" ? Well, for a start my c2dm acct is restricted to "just" 100,000 messages per day. I guess you're buying the drinks if you hit that !!
Chess is often played by email. You could do that.
Of course, any centralized/federated messaging system will work.
What might be better for your use is to add a jabber client to the application and have the program generate an account name that is used for automated messaging. You could host the jabber server or generate the accounts on a free provider.
Google App Engine if you know Python or Java.
Alternatively there are two web app API styles in wide use today: SOAP XML and RESTful web services.
If you know RoR I would recommend using JSON/REST, because you can just use Phusion Passenger with Apache to deploy your app. Free, extremely easy, and makes your server very reliable.
You could, and I only mention this because my friends do this all the time, use twitter as a server between the games.
I also found a lib called mages which looks quite promising.
Good luck.
I did this for my online 2D rpg: http://developingthedream.blogspot.com
Basically, use a middle-man server to co-ordinate data between all your clients.
You simply open a socket and communicate with the middle server and it takes care of passing on the information to any other connected clients.
I wouldn't recommend C2DM because of the message limit, and because the latency is still to big. Using your own server you can optimize it, plus you'll be the only one using the service so your data will be delivered faster.
I think that C2DM is not right way for playing chess because there is no warranty that messages will be delivered. You need more reliable way for data transfer