Courses

Module 12: Creating an Uber Clone Transcript before we proceed into the actual driver app work and push notification we need to implement all the infrastructure in the server side i also need to implement some changes we need in the protocol start by looking at the uber class i had to add three new fields and modify slash add some methods hailing from and healing 2 allows us to communicate our trip details with the driver community i need the push token of drivers so we can hail them directly from the app i’ll discuss the ride dao class soon it allows us to send the details about the trip to drivers not much of a change but i added the push token to the user dao factory method ride isn’t as simple as rydao despite their common name it contains far more information currently we don’t use all of that but the fact that it’s logged will let you provide all of that information within the app or a management app easily the right class is a jpa entity similar to the user class i used an auto increment value for the id instead of a random string i wanted to keep things simple but notice this can expose a security vulnerability of scanning for rides the passenger and driver are relational database references to the respective database object representing each one of them the route itself is a set of waypoints sorted by the time associated with the given waypoint we’ll discuss waypoints soon enough but technically it’s just a set of coordinates i really oversimplified the cost field it should work for some and currency but it’s usually not as simple as that it’s important to use something like big decimal and not double when dealing with financial numbers as double is built for scientific usage and has rounding errors we have two balloon flags a ride is started once a passenger is picked up it’s finished once he is dropped off or if the ride was cancelled the companion crude ride repository is pretty standard with one big exception i added a special case finder that lets us locate the user that is currently hailing a call notice the syntax b dot driver dot id equals question mark 1 which points through the relation to the driver object the waypoint entity referenced from the right entity is pretty trivial notice we still need a unique id for a waypoint even if we don’t actually use it in code the interesting part here is the time value which is the value of system current time melees this allows us to build a path based on the time sequence it will also allow us to reconstruct a trip and generate additional details such as speed cost if we wish to do that in the future notice that there is also a waypoint repository interface i’m skipping it as it contains no actual code the right service class serves the same purpose as the user service class focusing on rides and driver related features i could have just stuck all of this logic into one huge class but separating functionality to different service classes based on logic makes sense we manipulate both the rides and users crude objects from this class healing is a transactional method this means that all operations within the method will either succeed or fail depending on the outcome this is important to prevent an inconsistent state in the database this method can be invoked to start and stop hailing in this case we use the assigned user property to detect if a driver accepted the ride if so we return the driver data to the client when a driver gets a notification of a ride he invokes this method to get back the data about the ride if the driver wishes to accept the ride he invokes this transactional method the method accepts the token from the driver and the id of the user hailing the right it creates a new write entity and returns its id from this point on we need to refer to the right id and not the user id or token start ride and finish ride are invoked by the driver when he picks up the passenger and when he drops him off normally finish ride should also handle elements like billing etc but i won’t go into that now the next step is bringing this to the user through a web service the ride web service class exposes the ride service call almost verb team to the client the get call fetches the right dial for the given user id start and finish rides are again very simple with only one argument which is the ride id we also have to add some minor changes to the uber service and location service classes let’s start with the user service class drivers need a push token so we can hail them this is always set outside of the user creation code for two reasons the first time around the user is created but the push key isn’t there yet it arrives asynchronously push is re-registered in every launch and refreshed so there is no reason to update the entire object for that the user web service class needs to mirror these changes obviously there isn’t much here we just added a new set push token url and we accept this update the location service needs a bit more work every time we update a user’s location we check if he’s a driver on a ride assuming we have a ride object we check if this is currently an ongoing ride that wasn’t finished if so we add a waypoint to the ride and update it so we can later on inspect the path of the ride this pretty much tracks rides seamlessly if we wanted to be really smart we could detect the driver and use a position to detect them traveling together and automatically handle the ride there are obvious problems with this as it means a user can’t order a cab for someone else but it might be an interesting feature since we have two close data points

Module 12: Creating an Uber Clone Transcript the code for morph transitions broke another thing it broke the facebook or google login form which looks awful going in now because morph is generally designed for a specific form i want to use the vertical cover effect which is common on ios and looks pretty decent on android 2. cover slides the form on top of the existing form from the bottom it’s usually combined with uncover which slides the form out in the reverse way because of this unique semantic the cover transition uses both the in and out transition flags however this can pose a problem with the default out transition of the form that we are leaving in this case you would see the out animation of the login form which in this case is morph followed by the incoming cover animation the solution is to remove the out animation from the outgoing form and restore it to the original value when we get back we do that within the remove transition temporarily method which we call here from the facebook or google login form we need to remove both the in and out transitions as we might show a cover transition on top of another cover transition form when we return to the original form we restore its transitions to their original values we remove the show listener to prevent a memory leak and multiple restore calls when going back and forth

Module 12: Creating an Uber Clone Transcript when i started on this road i didn’t want to create a driver app and wanted to focus only on the client app unfortunately a driver app is unavoidable as the main app is useless without it unlike the main uber app i don’t want to clone the driver app as this would throw the whole course out of focus i decided to hack the existing app to implement driver specific features there and as a result we use a whole lot of code this means the driver app can reuse sign up map networking code etc this is important as code reuse breeds stability and maturity unfortunately it also means the app isn’t as well made as the main app since it was designed for end users with driver mode tacked on top Use Cases we often build one app and sell it to multiple customers after all most customers ask for similar things with minor changes for example if i build a restaurant app and then sell it to one establishment i can then resell it to another one with almost no change at all another common use case is the demo or free version of a paid app you want to use as much of the work as possible without maintaining two code bases another case which is relevant what i’m building today is two target audiences of roughly the same functionality for instance in this case the driver app has many common elements with the passenger app so why not build the same app with minor modifications the first thing we need to understand is how the app store identifies your application pretty much all apps use a unique identifier a string that is similar to package names which we map to which we map the main application package name so the trick is to add a new package for the new app Creating a New Package the basic hello driver would be something like this notice i chose to override the methods but i didn’t have to i could have just derived the main class and that would have been enough but i prefer overriding the lifecycle methods for clarity in this case this isn’t enough though the codename one settings properties file contains all of the internal configuration details about project i copied it aside and renamed it to codename one settings user properties i then edited the file to use the driver details and copied that into codename one settings driver properties notice i snipped most of the text here and there are several other locations where the values are mentioned Updating the App it’s important to update the app id to use your apple developer account prefix and package name this is automatically generated when you run the signing wizard to create ios developer certificates these certificates should be the same between the driver and the user app however provisioning profiles should be generated for both when you build an ios version of your app update codename1 dot main name to match the class name update codename 1 package name to match the package name other than certificates there are many nuances you would probably want to customize in this file such as the app name and the icon once this is all done you would have a separate app that does the exact same thing Driver Detection it’s really easy for us to detect the driver app and write custom code for it first let’s change the uber clone class to add driver detection this introduces a public is driver mode method into the uber clone class it would always return false unless we made one tiny change to driver app this is a block within driver app class we can now invoke his driver on the uber clone class and get the right result Push Notification i’ve discussed push notification before in the beginner course please make sure to follow the registration instructions there and update the values in the globals class once those are in place we can integrate push into the driver app we need to register for push every time the app loads the logic is that the push key might change so we need to keep it up to date we send a type 3 push which will invoke this code twice the first time around will receive a hash symbol followed by a numeric id the second time will receive a the display value when we receive the display value we can show a notification to the driver and if he clicks this notification we can show him the details of the ride ideally we would also have a rides menu item in the side menu but for now i’m compromising on the driver app to move forward when register succeeds this method is invoked the main use case is sending the push key to the server so it can trigger push messages notice that the device id is not equal to the push dot get key value device id is the historic native device key and shouldn’t be used also notice i send this every time even if the value didn’t change it’s not a big deal in terms of overhead so i ignored that small bit of overhead

Module 12: Creating an Uber Clone Transcript before we go into the big ui changes let’s go over some of the networking level level changes in the code in order to encapsulate the new ride json object from the server i added an equivalent properties object locally the class is practically identical to the server side ride dao class but uses the properties syntax instead of the standard pojo syntax the driver service class is a static representation of the driver specific server api this field represents the id of the current ride from this driver here we have the standard get method i mentioned earlier to retrieve the ride details and return them via a callback we use accept to indicate a driver is accepting a user’s healing if he doesn’t we don’t care once accepted he gets a reference to the id of the newly created ride object and the server notice that failure is indeed a possibility for example if the user canceled the ride or a different driver accepted first when we invoke start ride and finish ride we use current ride id unlike the user id which we used to create the ride in search service we had to add support for geocoding before this we only had the reverse geocoding which we used to locate the from slash 2 points on the map we need this api since the driver only gets the two slash from location names and we want to plot them on the map there isn’t all that much to say about this method it just searches the google geocode api for a location with the given name and returns the coordinates of that location there were many small changes in the user service class most of them relate to the way identity is managed in the app one of the big problems in having two applications with one project is that both projects share the same data in the simulator so if i want to launch the project twice once to run the user version and once for the driver version i will have a problem both will inspect the same storage information and use the same user identity they might collide notice that this is purely a simulator problem the simulator doesn’t currently isolate separate applications ideally this is something to improve in the simulator and might not be an issue in the future the solution is simple though we can just save the data to different locations or keys if we are in the driver app let’s review the changes this is illustrated perfectly in the first change in this class we use a different token to determine if the user is logged in for the case of a driver notice we replaced the invocations of preferences dot get token that were all over the code with this method call the preferences bind api lets us set a different prefix for the driver object that will be prepended to the properties in the preferences this is a cool little trick that allows me to debug with a fake number i used the is simulator method to log the verification code on the simulator and can just type it in even if the twilio code failed to send a message sends the push notificati token to the server right now we don’t need to do anything in the event callback this is invoked on registration success and allows the server to send driver push keys to the client after the first activation of the driver app we need to register for push notice i’m using the version of this method from the cn class with static import but the callback will go as expected into the driver app class

Module 12: Creating an Uber Clone Transcript the last two big ticket items are billing and social login i won’t implement them with adherence to the way they are were implemented with by uber i want to keep both of these features simple as they are both very volatile features and requirements within both of these apis can change literally overnight i will implement billing as a request before the write starts i’ll use braintree to do this mostly because it’s already implemented in codename one the original implementation in uber checks whether a billing method already exists this is possible to do in braintree but it would require some extra work to keep billing simple i’ll just charge one dollar per minute and do the charge in the server side in-app purchase is one of the big ticket features in mobile apps we support this rather well in codename one but we can’t use enough purchase for this case in-app purchase was devised as a tool to buy virtual goods inside an application this reduces friction as no credit card is needed google slash apple already have it and makes purchases more fluid the definition of virtual goods has some gray areas but generally the idea is that a good or service sold would be something that has no immediate physical cost good examples of virtual goods would be in-game item upgrade of software functionality app subscription etc however physical items and services are explicitly prohibited from using in-app purchase this isn’t a bad thing in-app purchase takes a hefty commission of 30 percent which isn’t viable for most physical goods sold braintree is a part of paypal and provides an easy to integrate mobile payment sdk for selling physical goods and services in theory we could just collect a credit card and call it a day but that’s naive securing online transactions is a nuanced task by using a trusted third party a great deal of the risk and liability is transferred to them one of the core concepts when working with the braintree is opacity the developer doesn’t get access to the credit card or billing information instead a nonce and token are passed between the client and the server even if a security flaw exists in the app a hacker wouldn’t gain access to any valuable information as the values expire this diagram covers the process of purchasing via braintree let’s dig into the pieces within it the client the client code our mobile app asks our server for a token the server generates a token with the braintree server code and returns it a client token is a signed data blob that includes configuration and authorization information needed by braintree to associate the transaction correctly it can’t be reused and should be hard to spoof in an attack the mobile app invokes the braintree ui with the token that ui lets the user pick a credit card or other payment option for instance paypal android pay apple pay etc then communicates with braintree’s server the result of all this is a nonce which is a unique key that allows you to charge this payment method our app now sends our nonce to our spring boot server the server uses the server side braintree api and the nonce to charge an amount amount to the payment method notice that the amount charged is completely up to the server and isn’t part of the client-side ui the braintree sdk for java is pretty easy to use we already have it in maven but just in case you skipped those lines this needs to be in the pom file next we add a braintree service class which is remarkably simple these values should be updated from braintree and sandbox should be updated to production once everything is working this is the client token that we use to identify the transaction notice we generate a new one for every request we save the nonce into the ride object this assumes payment authorization happens before the ride is completed once the rod is finished the nonce is instantly available to do to perform the charge before we proceed further the obvious next step is the web service to match it’s mostly trivial but i’d like to point out a small nuance pay isn’t mapped we invoke pay in the server so we don’t need to expose it to the client side that code requires some unexpected changes which i will get to shortly the first change was pretty predictable though we just had to add a non-field to the right class here’s the part i didn’t expect i needed to add the right id to the user object a driver has a reference to the right object which is why we didn’t need this up until now however when the user tries to pay he can’t set this anywhere else unfortunately there is no other place where the nonce would fit since it’s transient we can’t add it to the user as we’d want some logging the ride object is the right place for the nonce to get this to work i had to make a few changes to the accept ride method i added the right reference to both the driver and passenger for future reference i moved these lines downward because the rider id will only be available after the ride’s save call since payment is handled on the server side we can go directly to it even before we do the client side i’ve decided to do this in the finish ride method a ride that was finished before it was started is effectively cancelled a ride without a nonce can’t be charged at all i use the route which is ordered based on time to find the start time of the ride i then go to the last element and find the end time of the ride assuming the ride has more than one waypoint otherwise end time would be -1 we can just charge one usd per 60 seconds and payment is effectively done on the server again i oversimplified a lot and ignored basic complexities like the driver forgetting to press finish

Module 12: Creating an Uber Clone Transcript the last two big ticket items are billing and social login i won’t implement them with adherence to the way they are were implemented with by uber i want to keep both of these features simple as they are both very volatile features and requirements within both of these apis can change literally overnight i will implement billing as a request before the write starts i’ll use braintree to do this mostly because it’s already implemented in codename one the original implementation in uber checks whether a billing method already exists this is possible to do in braintree but it would require some extra work to keep billing simple i’ll just charge one dollar per minute and do the charge in the server side in-app purchase is one of the big ticket features in mobile apps we support this rather well in codename one but we can’t use enough purchase for this case in-app purchase was devised as a tool to buy virtual goods inside an application this reduces friction as no credit card is needed google slash apple already have it and makes purchases more fluid the definition of virtual goods has some gray areas but generally the idea is that a good or service sold would be something that has no immediate physical cost good examples of virtual goods would be in-game item upgrade of software functionality app subscription etc however physical items and services are explicitly prohibited from using in-app purchase this isn’t a bad thing in-app purchase takes a hefty commission of 30 percent which isn’t viable for most physical goods sold braintree is a part of paypal and provides an easy to integrate mobile payment sdk for selling physical goods and services in theory we could just collect a credit card and call it a day but that’s naive securing online transactions is a nuanced task by using a trusted third party a great deal of the risk and liability is transferred to them one of the core concepts when working with the braintree is opacity the developer doesn’t get access to the credit card or billing information instead a nonce and token are passed between the client and the server even if a security flaw exists in the app a hacker wouldn’t gain access to any valuable information as the values expire this diagram covers the process of purchasing via braintree let’s dig into the pieces within it the client the client code our mobile app asks our server for a token the server generates a token with the braintree server code and returns it a client token is a signed data blob that includes configuration and authorization information needed by braintree to associate the transaction correctly it can’t be reused and should be hard to spoof in an attack the mobile app invokes the braintree ui with the token that ui lets the user pick a credit card or other payment option for instance paypal android pay apple pay etc then communicates with braintree’s server the result of all this is a nonce which is a unique key that allows you to charge this payment method our app now sends our nonce to our spring boot server the server uses the server side braintree api and the nonce to charge an amount amount to the payment method notice that the amount charged is completely up to the server and isn’t part of the client-side ui the braintree sdk for java is pretty easy to use we already have it in maven but just in case you skipped those lines this needs to be in the pom file next we add a braintree service class which is remarkably simple these values should be updated from braintree and sandbox should be updated to production once everything is working this is the client token that we use to identify the transaction notice we generate a new one for every request we save the nonce into the ride object this assumes payment authorization happens before the ride is completed once the rod is finished the nonce is instantly available to do to perform the charge before we proceed further the obvious next step is the web service to match it’s mostly trivial but i’d like to point out a small nuance pay isn’t mapped we invoke pay in the server so we don’t need to expose it to the client side that code requires some unexpected changes which i will get to shortly the first change was pretty predictable though we just had to add a non-field to the right class here’s the part i didn’t expect i needed to add the right id to the user object a driver has a reference to the right object which is why we didn’t need this up until now however when the user tries to pay he can’t set this anywhere else unfortunately there is no other place where the nonce would fit since it’s transient we can’t add it to the user as we’d want some logging the ride object is the right place for the nonce to get this to work i had to make a few changes to the accept ride method i added the right reference to both the driver and passenger for future reference i moved these lines downward because the rider id will only be available after the ride’s save call since payment is handled on the server side we can go directly to it even before we do the client side i’ve decided to do this in the finish ride method a ride that was finished before it was started is effectively cancelled a ride without a nonce can’t be charged at all i use the route which is ordered based on time to find the start time of the ride i then go to the last element and find the end time of the ride assuming the ride has more than one waypoint otherwise end time would be -1 we can just charge one usd per 60 seconds and payment is effectively done on the server again i oversimplified a lot and ignored basic complexities like the driver forgetting to press finish

Module 12: Creating an Uber Clone Transcript next we’ll address the client side of the payment process before we begin we need to download the braintree cn1 lib from the extension manager right click the project and select refresh libs we’ll start the client side with the payment service class which encapsulates the web service aspects payment service has a private constructor so it can’t be instantiated by other classes we use the instance of this class to get callback events from the client side purchase api using the purchase callback interface notice that we need a ride id in the object instance so we can communicate purchase results to the server correctly this is literally the entire purchase api process we just invoke the native purchase ui and provide the callback instance for the native code on purchase success is the first callback from the callback interface it occurs when a purchase succeeded and produced a nonce we can then send the nonce to the server with the ride id on purchase fail or console aren’t very interesting in this use case i chose to ignore them but you might need them to know whether that the charge ui should be shown again notice the only way to verify purchase success is on the server fetchtoken is a callback method in the callback interface it’s invoked internally by the on purchase process to fetch the server token value that initializes the purchase process this is pretty much everything the only remaining piece is binding this into the ui i’ve changed the ok button to pay with cash and added an option to pay with credit which essentially maps to the braintree api this implements the four payment process integration including credit card verification and everything involved once this is done payments should now work both in the client and the server the user is presented with an option to pay or use cash which just dismisses the dialogue

Module 12: Creating an Uber Clone Transcript we already prepared a lot of the groundwork for social login on the server but didn’t finish all the pieces so before i step into the client side changes needed for social login let’s discuss some of the required server side work i had to include support for the exists functionality that works based on a social token i also had to include a similar call in the user web service class i also have a similar subtitle change to the regular exists method the argument name was phone and is now v which means i can invoke all three web services with very similar code on the client side that’s it pretty much everything else was already done social login lets us authenticate a user without getting into the username password complexity this is usually almost seamless on devices where we the pre-installed social app is invoked explicitly and the user just needs to approve the permission this is defined as a low friction approach to authenticate the user and is often superior to phone number activation in codename one this is pretty trivial to accomplish especially for google and facebook login both of which are built into codename one and to android slash ios respectively connection to social networks and codename one has several common concepts if the device has native support or social app installed this native integration will perform a login if it doesn’t but we are on the device the native sdk will show a web based login if we are on the simulator we will fall back to an oauth based login this leads to a situation where login might work on one device but fail on a simulator or fail on a different device type it also makes the configuration process a bit more tedious to be fair the native configuration is much harder and involves more code since the driver app is physically a separate app we’ll need to redo some of the steps and effectively go through everything twice a core concept of the login process in facebook is the app which is a facebook internal term unrelated to your actual app facebook’s view of an app is anything that uses the facebook graph api and authentication in this case we need to create a new app and should name it like we do our actual app so the user will be able to identify it the steps are pretty easy we navigate to developer.facebook.com apps and press the add a new app button next we need to select the product we are trying to use and we need to select facebook login once there we are presented with a wizard containing multiple steps to set up your app you need to run through the wizard twice once for ios and once for android the content of the wizard changes but the gist is the same we don’t really need much information and can skip almost everything the first step is download and install the facebook sdk for ios this is obviously unnecessary for us so we can just press next the second step is add login kit to your xcode project again there is no need to do anything and we can press next the third step is add your bundle identifier it’s more interesting we need to enter the project package name here and press save then we are effectively done with ios as everything else is more of the same the android wizard has one task that is a bit challenging but other than that it should be trivial before we begin we need to generate key hashes for facebook which need to be done on your development machine to do that you will need a command line with the jdks bin directory in your path you will also need the path to the android key store you use for signing you can find this file in the android signing section in codename one settings if there is no certificate file there make sure to generate it once all this is in place you can use this command line for linux mac this will provide the sha1 key you will need in the android wizard similarly on windows the command follows a similar structure but uses windows command line conventions now that this is out of the way let’s go over the android wizard steps the first step is download the facebook sdk for android this is obviously unnecessary for us so we can just press next the next step is import the facebook sdk again there is no need to do anything and we can press next the next step is tell us about your android project we need to specify the package name for the application which in our case is com codename1.app.uberclone we also need to specify the main class which is ubercn1 stub the main class is effectively the main class name with the word stub with an uppercase s appended at the end we can then press next after i press next i got this warning because the app isn’t in the store yet facebook thinks i might have typed the package incorrectly and provides this warning which we can ignore and finally we are at the add your development and release key hashes here we need to add the hash we got before and press next the rest of the wizard isn’t important before we proceed we need to enter the facebook dashboard and copy two values the app id and app secret which we will need when we set up the code

Module 12: Creating an Uber Clone Transcript next we’ll integrate the facebook login process into the code to get the native login working we only need one step add the build hint facebook.app id equals the app id app id is the id from the dashboard on the facebook app page this will make facebook work on the devices almost seamlessly notice that since we have effectively two apps we’ll need to add an app id to the user app and the driver app to get login working on the simulator we’ll need a bit more we’ll also need to write code that supports the login process within the facebook or google login form class facebook connect is a subclass of the login class that lets us login into facebook and request publish permissions if necessary the client id and secret aren’t used on devices these are hair strictly for the benefit of the simulator if you don’t need to debug on the simulator the lines until set callback are redundant notice that we have two versions of these values for the uber app and the driver app the callback is invoked upon login success failure if the login is successful we get the token from facebook which is an authorization token this token allows us to access information within the facebook graph api to query facts about the user notice that we have a new constructor for enter password form which i will discuss soon this triggers the actual login but the method is asynchronous and login will only actually succeed or fail when the callback is reached before we go to the google login support let’s look at the additional changes we need to get both facebook and google working i already discussed the changes to enter password form so let’s start there the constructor accepts one of the three options the other two should be null in this case i also updated the user service method accordingly i’ll get into that shortly notice i snapped some code below here to keep the entire block in one page but it’s still there the login method now accepts the google facebook credentials as an optional argument two of the three values for identification will be null so we can set all of them and only one will have a value next let’s see the changes to the user service class this is the main method we use which we broke up for the other types the generic implementation demonstrates why i chose to change the argument names from phone to v so it can now suit all permutations of this method login is almost identical to the original code i added the new values to the mix if they are null the arguments won’t be sent and everything will work as expected once this is done facebook login should work on the device and simulator

Module 12: Creating an Uber Clone Transcript the last piece is the google login support which we almost finished as the code we did for facebook is nearly identical google again went through some back and forth originally it was mapped to google plus functionality as google phased out google plus we switched to use the new google login authentication the process for google is pretty similar to the one we had with facebook first we need to go to the google developer portal at developers.google.com mobile slash ad and follow the steps to create an app for google sign-in notice we need to run through the process four times once for android and once for ios and again for the driver app the ios version requires the app name and bundle id which map to the app name and package name in codename one next select the google sign-in option and click the generate button once we enable google sign-in we can generate the configuration files then we can download and the configuration file which should be named googleserviceinfo.plist place this file in your project root under the native ios directory the process for android is nearly identical with one big difference we need to provide an sha1 key for this to work since i discussed the process of generating an sha1 key for your certificate earlier i won’t repeat it again check out the facebook section for the details on that process once we finish this step we will receive a file named googleservices.json we should place this file under the native slash android directory in order to work in the simulator we’ll need some additional credentials from console.cloud.google.com apis in the top portion of the browser make sure the correct app name is selected select the credentials menu find the web client entry and click it you should see the client id and client secret values there we will need them in the code soon in the authorize redirect uri section you will need to enter the url of the page that the user will be sent to after a successful login this page will only appear in the simulator for a split second as codename one’s browser component will intercept this request to obtain the access token upon successful login you can use any url you like here but it must match the value you give to google connect dot set redirect url in the code once all of this is in place we can add the code to handle google login process you’ll notice that the code is almost identical to the facebook login code in fact both google connect and facebook connect derive the login class which means we can write very generic login code at least in theory