Должны ли приложения Android с серверным компонентом напрямую обращаться к Facebook?
Если я создаю приложение для Android, которое использует Facebook SDK, а также имеет веб-приложение, которое обладает практически такими же функциями, как приложение Android должно обрабатывать социальные действия? Должен ли он напрямую отправлять запросы в API Facebook через SDK или должен публиковать на сервере веб-приложений через мой собственный API и разрешать веб-приложению отправлять запрос в Facebook от имени приложения Android? Большинство примеров Facebook для Android используют первый подход, однако ни один из них явно не обсуждает лучшие практики, когда есть веб-сервер, который будет иметь такую же социальную функциональность, что и приложение Android.
3 ответа
Я занимался подобной проблемой раньше. Это было приложение PHP, но, по сути, выбор дизайна заключался в том, чтобы поместить FB-взаимодействие во внешний интерфейс (JS-SDK) или в бэкэнд и прокси его (PHP-SDK). К сожалению, не нашел много указаний, поэтому я должен был решить.
Поскольку часто кажется, что ответа как такового нет, это зависит от того, что вы делаете с FB, и насколько глубоко он интегрирован в то, что делает ваш app / webapp / backend. Является ли ваш Android в большей степени клиентским приложением или использует другие функции, предоставляемые веб-приложением через веб-сервис? Является ли он каким-либо образом интегрированным с действиями пользователей, отправляемыми на сервер, или он просто предлагает дополнительные уловки (например, кнопка "Мне нравится", что-нибудь в строках). Используете ли вы SDK для аутентификации и извлечения данных, относящихся к пользователю, из FB (электронная почта имя) и играет ли эта информация роль в вашем бэкэнде?
На мой взгляд, все сводится к следующему:
Прямое взаимодействие с FB намного проще в реализации, так как у вас не будет дополнительного слоя между вашим приложением и FB, то есть прокси-кодом и т. Д. Так что, если FB просто слабо связан, это, вероятно, вариант "достаточно хороший".
Патч FB от внешнего интерфейса к внутреннему может стать неприятным - особенно если вы хотите пройти аутентификацию через FB, сначала это довольно сложно. Тем не менее, вы будете иметь всю логику FB в одном месте, совместно используемую Android-App и Webapp, так что, очевидно, будет проще поддерживать ее позже и лучше интегрировать с другими взаимодействиями, которые может предложить ваш бэкэнд.
Надеюсь, что это дает какую-то ценность, хотелось бы увидеть и другие мнения.
Что ж, я думаю, что оба подхода верны, но выбор зависит в основном от того, что у вас уже есть на стороне сервера, и от того, планируете ли вы использовать одну и ту же функциональность в разных приложениях, таких как (Android,iOS, Windows Phone приложения). В этом случае имеет смысл просто получить токен пользователя с разрешениями, которые вам требуются, и позволить веб-серверу общаться с Facebook с помощью этого токена. Вы даже можете сохранить этот токен для пользователя, чтобы ему не нужно было снова давать разрешения, если, например, у вас есть веб-регистрация и регистрация приложения. В нашем приложении мы используем этот подход, поскольку в основном существует пять внешних интерфейсов (Android,iOS, Desktop,Mobile Web,Full Web), поэтому разработчики приложений просто получают токен, используя sdk на своей платформе (вы должны использовать токены, а не имя пользователя)., пароль из-за правил Facebook для безопасности). С другой стороны, если все коммуникации Facebook используются только внутри вашего приложения, и серверу не нужно много знать об этом, вставьте вызовы API в приложение.
На мой взгляд, лучше использовать доступные SDK /API для каждой конкретной платформы, а не пытаться написать свою централизацию и использовать одну библиотеку. Поскольку вас особенно интересует, как приложение Android должно обрабатывать социальные взаимодействия, я предлагаю использовать Facebook SDK для Android.
Несмотря на то, что это увеличивает размер кода, который вы должны поддерживать, и SDK /API, которые вы должны изучать при увеличении списка платформ, наиболее важным фактором для этого подхода является взаимодействие с пользователем. Придерживаясь собственных библиотек и расширяя свое приложение по мере развития этих библиотек, вы будете предоставлять своим пользователям опыт, к которому они, скорее всего, будут привыкать. Им не нужно будет учиться пользоваться вашим приложением, но они смогут создавать посты, обновлять свой статус и просматривать список друзей, используя элементы управления, к которым они привыкли. Кроме того, вы сможете воспользоваться преимуществами определенной функциональности платформы (в мобильном случае, например, публикация вашего приложения в фиде пользователей для продвижения вашего приложения: https://developers.facebook.com/docs/tutorials/androidsdk/3.0/games/feed/)