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/)
Related
Please forgive my (perhaps naive) question, I am still a beginner!
I have a website on asp.net core that is essentially a CRUD website. There are some Razor pages and some controllers. When the user is logged in, they can create and update the data they own (through javascript and said controllers).
Login is organised via Cognito's built-in UI. I redirect the user to it with the [Authorize] attribute on certain controller actions. The token (I think this is what it's called?) coming from Cognito is automatically stored in the browser cookie and is passed between the browser and the backend (controllers and Razor pages). In the backend controllers and Razor pages, I have very convenient methods like User.IsAuthenticated(), and can get claims and fetch cognito:username and similar fields.
The website is working well enough.
I am now working on native mobile apps (Android and iOS), and I am wondering how to deal with authorisation in them as well. I want the user to have the same experience in the mobile app as on the website: they would log into the mobile app and see and edit the data they created earlier on the website, and vice versa. I'm not sure how to implement this correctly. I see several options:
Option 1. Use the AWS amplify framework in the apps. I am sure it will work nicely; but how will I then pass the token to my backend controllers? Asp.net core needs it to build this User object, I understand. I think asp.net core stores it in the cookie appropriately named .AspNetCore.Cookies, but I'm not sure as to its format and whether it'll stay stable in the next releases?..
I'm currently reading about JWT bearer tokens, maybe that's the thing that should be used instead of .AspNetCore.Cookies?..
Option 2. I could "pretend" that the mobile app is the same as the browser and send exactly the same requests as my web frontend does. I suppose this sounds very complex - I'd need to store cookies, follow redirects (to the cognito built-in ui, for example) - I don't know if there is a built-in mechanism? However, in this case the app doesn't have anything to do with cognito, talks only with my backend, and is just following redirects. AppAuth states that Authorizing the user occurs via the user's web browser, so perhaps it can be used here?
Perhaps there are other options that I overlooked; I'm almost sure there is a simple solution I just can't see at the moment. Sorry it's all over the place, this is a very new topic for me. Thank you in advance!
I've just finished django app for multiple choice questions. However, I wanted to develop Ionic android app version of the web app. It's my first app and I am still learning web development. I'm not sure if Django RestFramework or firebase backend is more suitable for offline first app, particularly with respect to mostly text-based questions.
I suggest that you need to research the both options as there is a use case for each, but Django is not traditionally used for a mobile backend.
You need to weigh up the positive and negative of each and determine what suits your use case, at present you have not provided adequate information in order to make a determination either way.
Using Django as a backend is like saying you want to use WordPress as a backend, that is they are both content management systems that were not designed to serve as mobile backend Api's.
Additionally you need to consider the likelihood of your apps success, and what that means as a user count. If you feel that your app will be a success then don't waste your time with Django as you will very quickly have to spend money to scale the system.
The best option in general terms would be to use Firebase, a system specifically designed as mobile backend Api's.
However, to make an app like Uber, you’re going to require some custom server-side code. For example you’ll want real time updates of vehicle locations, availability, etc. This data can only be generated on the server since you’ll want multiple clients to access it at any given time. Firebase is probably too lightweight for this task, so making your own backend API would be a better option.
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'm busy building an app for android. When it's properly received by Android users I would like to expand to iOS.
But, before we get there, I first want to make the right choice. So my question, what to do?:
writing all the logic inside the app and use Cognito (https://blogs.aws.amazon.com/security/post/Tx3LP54JOGBE0AY/Building-an-App-using-Amazon-Cognito-and-an-OpenID-Connect-Identity-Provider) to access the data from DynamoDB
or let my app connect with my own API which handles the validation rules, which I then connect with DynamoDB database (don't know or API -> Cognito -> DynamoDB is a better solution, didn't really used it yet so...).
Now we all know about those issues where hackers built ways to bypass certain validation rules (as far as I read, most commonly by decompiling the app). I really want to avoid that!
So what do you experienced Android developers use? I know the answer seems obvious. But the reason I ask this is because I would like to avoid having my infrastructure, which I need to update etc. But to be able to register users, without the need of an third party which supports OpenID like twitter, facebook or Google, AND secure my validation rules, it seems like I have no choice. Or do I?
If you are targeting multiple platforms, it's usually best to conduct the majority of your business logic in an api outside of the app. It reduces code duplication and if validation is done at the api level, it limits the ability of malicious users to bypass validation rules.
With that said, running your own api doesn't necessarily require running your own infrastructure. Two AWS web services that could help are Amazon API Gateway and AWS Lambda. Registering your users can be done using Amazon Cognito Your User Pools.
I'm working a mobile application for Android and iOS (native in both cases) that will be using Database.com behind the scenes as the database. I need this intergration to be tansparent to the user. The users of the app will not be logging into or authenticating with Database.com at all, it should simply be working behind the scenes a cloud database. I will simply be using an integration user hardcoded into the application.
I've been having an extremely difficult time of finding any of examples of how to build an app with the MobileSDK where I don't have to take advantage of the user-agent OAuth flow that displays a view to the app user. zkSforce has been mentioned as a possible solution for iOS (and it looks like it could be) but I haven't found even any basic tutorials on how to implement this with inconjunction with the mobile sdk to get access to the REST API (by bypassing the login view for the user). I also have yet to find anything at all for Android other than just taking advantage of the standard Java SDK or importing the web service wsdl and working from there through SOAP.
So is there anyone out there who can point me in the direct of some examples of behind the scenes authentication and use of the Mobile SDK REST methods or is my best option here to go to using the SOAP solutions behind the scenes?
Take a look at the OAuth 2.0 Username-Password Flow, which will allow you to use already known username and password with an OAuth-style flow. This is preferred to making a SOAP call in an app that is using the REST API everywhere else.