blackberry / WebWorks-Community-APIs

Community owned repository containing JavaScript Extensions for BlackBerry WebWorks

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Finish Facebook Connect merge into PhoneGap plugin

timwindsor opened this issue · comments

A Facebook Connect plugin is available in this repo. We need to merge it into the PhoneGap Build plugin for upstreaming

Most of the work will be in moving BlackBerry 10 specific items into the index.js file, and out of the client.js file, which needs to be consistent across platforms.

#330 is associated with this issue

A ton of the work is done for this already by @jstncarvalho. Only a few small updates needed, if he doesn't get a chance to finish them up.

Fun fact: When you add the fb plugin format it like this:
cordova plugin add plugin --variable APP_ID="you id" --variable APP_NAME="your appname"
You need a facebook app and fill in the two variables with the information from the app

Another fun fact: The DEV_TODO file is out of date as it seems the showDialog box has already been implemented with the following commit:
blackberry/phonegap-facebook-plugin@4a75dfa

Besides that, only remaining thing seems to be to standardize the return types

Was trying out the different methods in the plugin, and I noticed that log out doesn't actually log out. I kept getting errors with my initial call and then a success with a subsequent call. Looking through it, I see a couple problems with the implementation:
1.) We return a successful logout even if we don't actually log out. This is inconsistent with the other plugins that will error if we do not have a session open. Already have a fix in mind using some powerful javascript calls.
2.) We are using a variable that doesn't exist which causes the error, going to see what the value of it should be and then use it. Might have been some issue during the merge

Tried the showDialog Method using the example code given in the Wizcorp/phonegap-facebook README and got an error saying we don't support the feed method. Looking at some documentations it seems what was implemented technically is what is defined for a showDialog box. That being said, it seems like this api method is suppose to do more then that. Is this something I should look at? When I tried the second example code which was a valid method for the showDialog box, I got an error again complaining about now redirect url. This was using provided example calls in the Wizcorp readme, so if our goal is to be congruent with Android and IOS plugins this might be something that should also be fixed

See what you can find out - it may be that the samples, or the library we are using are out of date. Facebook tends to change things pretty quickly, so it's hard to say where the issue might be.

The shareDialog method needs more work. I've identified several things that could be improved in it already:
1.) Closing the dialogue after finishing the command
2.) Implementing proper handling of the "feed" method
3.) Make existing calls more robust to handle changes in the number of potential parameters available
4.) Change the error handling to now flash an alert message in your application

I'm sure there are more, but just some quick things I've identified

^ Also, should it happen that I don't finish this issue. If you look at the documentation, there's actually another method available in facebook called "send". This is not supported in the mobile platform presently so no need to add it

Found a work around using invoke plugin to create a default share dialog when the required parameters for the shareDialog methods: "share" and "share_dialog" are not provided. However, it requires the user to be logged into the BB10 facebook application otherwise it will just pull open a facebook page asking them to do that. The other thing is, I found if you try making the invoke call with an empty string, sometimes it'll just close without warning. To remedy this I found a single white space character keeps this from happening.

Figured out response data thing for showDialog. So, if there is response data, it appears at the end of the redirect uri, so I guess some parsing will need to be done in order to get it from there. the end string seems to be : '#=' after the responses so probably will be able to use that.

Added README and changes for login. Found out rerequesting every time login is called will work so I implemented like that. Nothing else that I can think of for my commits besides maybe double checking all methods on my end. Mostly gonna just wait for review for my pull request otherwise.