I would like to use Stripe on Android App.
I can read docs and see samples.
I can see that samples show us that Charge should be done by 'our backend'
not by Android app.
but I had heard that client app should be possible to do payment without backend. I mean, directly to Stripe.
I saw old samples, where it was able to use Charge class from android app, but this class is not available now.
Can someone explain, what part should do Charge?
I mean, client or backend?
Its a good approach to send token to your server for charge.The only part which should done at your end is collecting the token which you'll get by stripe api.
The reason behind all this is security and memory usage.As the sever has more memory comparatively app, its good to perform all computations there.
Related
using the graph API, I can very well make a query like this :
{facebook-page-id}/photos?type=uploaded
This question has to be more on the theoretical side.
I'm working on an android application that has to show the images(uploaded photos) from a particular facebook page. Now, I can access all the pictures using the graph API and the queries.
My question is regarding the feasibility of this approach. Do I have any other method that is better than this, given the limit that facebook puts on requests generating from a single device with a single token.
Although Graph API can easily do that, is there any other approach to it ?
Your only option (on any platform) will be to use Graph API.
What you are describing sounds like a form of page management app, which is not necessarily something that makes a lot of sense on a mobile device. The reason is that the number of requests required to fetch the information you are requesting can easily become enormous.
When doing this in a web application, you can leverage a web server's virtually infinite storage capacity and bandwidth (compared to a mobile device), and you can even reduce the amount of Graph API requests by implementing RTUs. The latter is impossible on a mobile device, as you need a live web endpoint capable of receiving RTU callbacks from Facebook.
I am to build an android app that needs a central cloud storage (along with some server coding). My app is somewhat in the footsteps of
https://play.google.com/store/apps/details?id=com.justyo
I mean i should be able to store a login and registration (possibly FB login in the future too). Then, i will also have to maintain and fetch users' 'friends' in the app along with a status (that can be changed any time by the friends).
I am not new with android dev. I also know ample amount of web development. However, i don't know the approach to this kind of an app that is to use some server side code and online db for android.
I have search a lot on the internet and have found a bunch of stuff, but i am just not getting the confidence as to which approach is what i need here.
Is there something pre-built and given by Google themselves?
Do i have to by a domain, deploy a hidden (UI-less) web service and access it through the android app?
is there a free option out there by google?
Is there a sample demonstration android app out there?
I don't need the code or anything. I am just confused; afraid of starting off in the wrong direction. Please answer so it is easy to understand.
Thank you in advance :)
There is the Google Cloud Platform, specifically App Engine. You can read the Docs here.
You dont't need to register a domain to use the platform. Yes, you will need to deploy a (not necessary UI-less) web service to the cloud, accessed from the Android client through endpoints. Additionally, the service is free up to certain limits.
Sample apps are available for deployment once you create a project from here.
If I am building an Android app that uses the Facebook SDK and also has a web app that has most of the same functionality, how should the Android app handle social actions? Should it directly make requests to the Facebook API through the SDK or should it post to the web app server through my own API and allow the web-app to make the request to Facebook on behalf of the Android app? Most of the Facebook for Android examples use the former approach however none explicitly discuss the best practice when there is a web backend that will have the same social functionality as the Android app.
I've been putting my mind into a similar problem before. It was a PHP app, but essentially the design choice was to either put the FB-interaction into the frontend (JS-SDK) or into the backend and proxy it (PHP-SDK). Sadly haven't found much guidance either, so I had to make up my own mind.
As so often there seems no per-se answer, it depends on what you are doing with FB and how deep it is integrated into whatever your app/webapp/backend are doing. Is your Android otherwise more a client-side app or does it rely on other features delivered by the web-app via web-service? Is it somehow integrated with users actions that are dispatched to the backend, or does it just offer some additional gimmicks (e.g. 'Like' button, anything in the lines) Are you using the SDK to authenticate and pull user related data from FB (email, name) and does that information play a role in your backend?
As I see it, it boils down to the following:
Direct communication with FB is a lot simpler to implement as you won't have an additional layer between your app and FB, i.e. proxy code, etc. So if FB is just loosely coupled it's likely the 'good-enough' option.
Patching FB from frontend to backend can get nasty - especially if you want to authenticate via FB it's kinda complex at first. However, you'll have all FB logic in a single place, shared by Android-App and Webapp, so it's obviously easier to maintain later and better to integrate with other interactions your backend might be offering.
Hope that provides some value, would be eager to see other opinions too.
Well I think both approaches are correct but the choice depends on mostly what you already have in place on the server side and if you are planing to use the same functionality from different apps like (Android,iOS, Windows Phone apps). In that case it makes sense to just get user token with permissions you require on the front end and let the web server talk to facebook using that token. You could even save this token for the user so they don't have to give permissions again if for example you have web registration and app registration. In our app we are using this approach since there are basically five front ends (Android,iOS, Desktop,Mobile Web,Full Web) this way application developers just get token using sdk on there platform (you have to use tokens and not user name, password because of facebook rules for security). On the other hand if all Facebook communication is used only inside your app and the server doesn't need to know much about it put api calls in the app.
In my opinion, it is best to use the available SDKs/APIs for each given platform instead of trying to write your own centralization and use a single library. Since you are specifically interested in how the Android app should handle social interactions, I suggest using the Facebook SDK for Android.
While it does increase the size of the code you must maintain and the SDKs/APIs you must learn as your list of platforms increases, the most important factor for this approach is the user experience. By sticking with the native libraries, and growing your app as those libraries evolve, you will be providing your users with an experience that they are most likely to be used to. They won't have to learn how to use your app, but will be able to make posts, update their status, and look at their friend list using controls that they are accustomed to using. Additionally, you will be able to take advantage of specific platform functionality (in the mobile case, such as having your app post to a users feed in a way that promotes your app: https://developers.facebook.com/docs/tutorials/androidsdk/3.0/games/feed/)
I have a MVC application that I would like to port at least a small part of it to a mobile app (android first). My first objective was to try to figure out how to authenticate the users.
It seems that forms based authentication uses cookies and that is not usable by mobile apps? Definitive confirmation would be appreciated.
But it seemed that you could do some form of authentication using a WCF service to create a token. Now I found a lot of sites that discussed how to create and secure the service end point but none really discussed the token generation.
Then quite by accident I stumbled upon WIF and the usersecuritytoken, which seems to what I am looking to accomplish.
So if some could please confirm this is where I need to be looking so I can actually get back to coding rather than reading I would appreciate it.
The way I see this working is:
Secure WCF service.
Using the System.IdentityModel it generates a token for a valid user and passes it back to the mobile app.
Then the app passes the token along anytime a service requiring privilege is called. For example updating the user's profile.
Is that how it is suppose to work? If not could you please point me to an example of how it is suppose to work.
One other question, looking at the WIF site it seems to provide a lot of token types, what is the preferred type for android and iOS?
UPDATE As it was pointed out it would be helpful if I provided more context.
The original website is a MVC3 web app.
I am attempting to write an app for some of the backend administration features using mono touch.
WCF seems to be a bad solution for cross platform and a package called ServiceStack is what I am now leaning towards for my web services. ServiceStack has its own authentication module but it does not interface with the .net membershipprovider which is an issue since the web app was designed with the membership provider.
I have to be overthinking this. It can't be this complicated to have an android or iphone app securely authenticate to a .net membership provider through some form of web service.
Thank you in advance,
Chris
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