weixin_39574868
weixin_39574868
2020-12-09 07:37

Add ability for FBSession to load FBAppId, WindowsAppID from resources

On phone in particular, if an app is tombstoned that session can lose its information like token, app IDs, etc., and the app developer shouldn't have to write code to reset these values. Rather, the session should just load them from string resources with a well-known name.

该提问来源于开源项目:microsoft/winsdkfb

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

7条回答

  • weixin_39574868 weixin_39574868 5月前

    Updated the title of this issue to reflect current understanding that we won't make the resource file the exclusive way to set app IDs.

    点赞 评论 复制链接分享
  • weixin_39867200 weixin_39867200 5月前

    Open Ask: identify an optional model to use resources to store the FB App ID.

    点赞 评论 复制链接分享
  • weixin_39761647 weixin_39761647 5月前

    The C# SDK does this by having a XML Why not just do that? The Windows manifest is not extensible AFAIK, so this seems to be a logical step to keep the configuration outside.

    点赞 评论 复制链接分享
  • weixin_39760389 weixin_39760389 5月前

    Developers can load the FB App ID and Windows App ID from a Resources.resw file if they would like to avoid hard-coded strings in their source. See the Login-Cpp sample app to see an example of this.

    点赞 评论 复制链接分享
  • weixin_39967996 weixin_39967996 5月前

    That assumes that every app has string resources. Of course, the feature could be implemented in a way to still allow programmatic setting of these values which is an API design that will always work.

    点赞 评论 复制链接分享
  • weixin_39574868 weixin_39574868 5月前

    Yes, this may be a problem for unusual cases, like a desktop (Win32) app using the SDK. For a regular Store (modern UI) app, adding a resources.resw file and inserting a couple of well-known values ends up simplifying the programming model quite a bit, though, so it's worth doing. As long as the properties on FBSession are writable, the app can still handle this appropriately, and I don't see any reason to make them read-only, so we're probably okay there.

    点赞 评论 复制链接分享
  • weixin_39967996 weixin_39967996 5月前

    I agree that leaving them writeable is very good. I also agree that reading them from some standard resources file will be helpful for Windows-only codebases.

    However, I speak from experience. We have to jump through hoops at times to support Android because some Android libraries do the "load the values from resources" scheme, in fact I think the official Facebook SDK does this. iOS often does the same with their plist resource files. Our game compiles for linux, osx, win32, ios, winrt, winrt/phone, html, android, android/fire, android/, and someday win10. Supporting the OS-specific configuration files for each platform is a drain on our dev resources and error-prone( because you always forget to update one of them, right?).

    -ted

    On Fri, Jul 24, 2015 at 12:37 PM, Blake Bender notifications.com wrote:

    Yes, this may be a problem for unusual cases, like a desktop (Win32) app using the SDK. For a regular Store (modern UI) app, adding a resources.resw file and inserting a couple of well-known values ends up simplifying the programming model quite a bit, though, so it's worth doing. As long as the properties on FBSession are writable, the app can still handle this appropriately, and I don't see any reason to make them read-only, so we're probably okay there.

    — Reply to this email directly or view it on GitHub https://github.com/Microsoft/winsdkfb/issues/10#issuecomment-124666650.

    点赞 评论 复制链接分享

相关推荐