This document contains in-depth information about the Facebook* example application. In addition to this document, you can find more information in the code and in the HTML documentation (the index.html file in the "HTML documentation" directory).
The Facebook* example application displays a dialog that lets the user log in to Facebook*, on a successful authentication; it then displays information about the user.
The Facebook* example application demonstrates how to authenticate a user on the Facebook* platform and displays the resulting authentication token. The Facebook* example was developed on the MFC framework as a single document interface but with multiple views. A document/view architecture was chosen because of its compatibility with the widest variety of user interface MFC elements. The application uses the FacebookExampleComponent for all interaction with the Facebook* platform. The application uses the FacebookExampleComponent as a static library.
This application can be conceptually broken down into two discrete states, an authenticated state and an unauthenticated state. In the unauthenticated state (which is active at startup), the application presents the CFacebookComponentView as its active view, and instructs the view to authenticate the user. Once the user has presented valid credentials, the application transitions to an authenticated state, and the application's internal view is made active by the mainframe window. The Facebook* component view class may be retained to execute back end requests if desired.
The FacebookExampleComponent is a static library featuring a single class: CFacebookComponentView. This class is based on two classes using multiple inheritance: the MFC CHtmlView and the Intel ADP Component classes. The CHtmlView was chosen as it encapsulates the Microsoft Internet Explorer* libraries, providing a browser interface that nicely integrated with MFC. The CFacebookComponentView class features one method, Authenticate(), which instructs the view to navigate to the Facebook* login URL and detect a successful login.
Technical Implementation Summary
In designing a desktop implementation of a social networking client for the Intel AppUp® SDK, we had a few challenges.
- First, we were some of the first developers to use their new framework.
- Second, we had the goal of integrating with the authentication requirements of several systems.
- Third, we had the goal of providing a body of code that was both representative in terms of best practices as well as easy to understand and adapt.
The CHtmlView appeared to be a good candidate, as it was designed to work within the document/view architecture of MFC and provided a simple interface to HTTP functionality. About the only issue was that originally the application was designed with the goal of not having an explicit dialog box, but this was not feasible. The application can be thought of having two basic states: an authentication state and an operational state. Each state is supported by a distinct CView class. For login, the CFacebookComponentView is made the active view for the application. After a successful login, the main frame window class is notified of the state change, and the CFacebookExampleView class is made the active view. The views are modal in themselves, so there is little reason to pop up a dialog box. Avoiding dialog boxes can also provide a better user experience on devices with limited screen real estate, such as netbooks and portable devices.
After successful login, a developer may opt to maintain the CFacebookComponentView instance to serve as the underlying API layer for additional functionality. To support this, component developers may explore extending the Facebook* component with an API that wraps the Facebook* service. While this route may incur some overhead in terms of dealing with Microsoft's DOM and XML APIs, it's probably easier than importing the WinINet libraries.
On the component side, there was one additional challenge in designing a library suitable for MFC. The project creation wizards really focus on the creation of DLLs for MFC libraries. While it is possible to include MFC headers for static libraries, it wasn't the option of choice for the MFC team at the time that the tools were created. For Intel, the focus has been on static libraries for components. This eliminates the possibility of version issues that can crop up when dynamically loaded libraries are employed. Additionally, linking with static libraries helps to eliminate a potential security weakness.
Initially, we created the component as a DLL, but discovered an unfortunate side effect of this arrangement. Dynamic libraries require their own link phase, since they're essentially a stand alone entity. This meant that they linked directly to the ADP libraries which resulted in a duplication of code, with the DLL and EXE containing separate copies of the library. Any globals that were maintained by the ADP library were subsequently not shared between the ADP application and component instances. At application startup, this resulted in an initialization failure.
Finally, we also created a prototype project, incorporating the base functionality required for a functional ADP application in MFC, as a starting point for our sample applications. It's a bare-bones framerwork, incorporating hooks for power management, device events, and ADP component integration. We hope that this will serve as a good template for your future applications.
All in all, we really enjoyed the developing the sample code base, and hope that you find it both educational and useful.