Smartphone against Pocket PC Phone Edition
You may have heard of Pocket PC Phone Edition, which is another phone that is equipped with Microsoft software. In order to avoid confusion, I will clarify the difference between Pocket PC Phone Edition and SmartPhone. Figure 1 shows the difference between the two (if you are interested in reviewing information about the SMARTPHONE graphics interface, you can view "Development Efficient Smartphone User Interface"). Pocket PC Phone Edition is a Pocket PC device that is fully built-in built-in mobile phone capabilities. In size it is similar to other Pocket PC devices, the volume is larger than smartphone. Pocket PC Phone Edition requires a larger power and more memory; in addition, it has a touch of touches, the area is much larger than the usual Smartphone screen (it does not support touch,). The interaction path of users and devices is also different: Pocket PC Phone Edition uses the input pen and the touch mutual interaction, while smartphone uses the phone's keypad.
Figure 1. Screen comparison
Which type of device is suitable for you, depending on the three main factors: the cost, function and the simplicity of use. Microsoft estimates that Smartphone is similar to other high-end mobile phones, which is lower than the Pocket PC Phone Edition. What you need is detrimental to what the application is designed. The same is true for most mobile applications, SMARTPHONE and POCKET PC Phone Edition. However, if the application requires a large amount of disk space and memory, additional hardware or large screen, Pocket PC Phone Edition may be the correct choice.
No matter which device and the application running on it, it must be easy to use, and you should consider the problem of data input. First, you must decide to use the input pen or a keypad, which is actually there is no relationship. The data input through the menu option is easy to be processed by other devices. However, if you enter text information, Pocket PC Phone Edition is significantly better. Fortunately, both devices support Windows CE API to make it easily established a base code for them.
Create a SmartPhone app
What does the real SmartPhone application need to pass? Many transactions in most mobile applications are common. They retrieve data, process, save data locally, upload changes and interact with telephone features locally offline. If you can understand and build these elements when you need it, you can develop in real SmartPhone.
The next step is to determine the type of application that will be established: Browser-based, Standalone.
Browser-based scenarios on Smartphone contains web content that can be accessed by the Pocket Internet Explorer. This type of application is the best choice for existing content providers, they want to extend the sale to the Smartphone owner. Browser-based applications on Smartphone is the same as the benefits on other platforms: simple software distribution and maintenance, because all code is on the web server. Of course, the disadvantage is that it does not guarantee that always is always connected to the Internet. Another problem is that the pocket internet browser application cannot interact with the built-in characteristics of the device. Despite this, such applications can develop and optimize tools using existing (eg, ASP.NET mobile controls) Web development.
Unlike the web application, you can develop a customized application using tools with embedded Visual C . Fortunately, Smartphone is similar to the Pocket PC platform. Because most APIs are the same, applications developed using embedded Visual C for Pocket PC platforms can be simply ported to Smartphone, and the result is a large extent, which costs the cost development for two devices. I transplanted two applications, one need to simply recompile, and another spent a few hours to solve the weak difference between the platform. When you develop an independent application, you have more flexibility, which is often more secure and can be used to connect and not connect. For most commercial applications, the independent application may be the best choice. They are used in offline environments, as well as mechanisms that deliver data between remote systems.
In addition, stand-alone applications can also use specific devices, including technical features, and access local data storage, such as Pocket Outlook, and Windows CE Database (CEDB) engines. When offline, the data can be stored in order to synchronize. However, independent applications face more distribution and maintenance issues. In addition, establishing a stand-alone application requires C experience, usually its cost is higher and difficult to find developers. But this situation will not happen, and Microsoft will finally support Smartphone. If this is implemented, developers can establish Smartphone applications using languages such as C # and Visual Basic .NET.
Data retrieval
Because any commercial application is the most basic characteristic is to retrieve data, some issues designed around the available connection. Can you rely on a continuous connection or connection may be interrupted? Is your system only have a certain number of times and the access point need to be connected?
Smartphone provides several options for retrieving data from remote data source. One is ActiveSync, you can use it to push / pull / pull / pull between desktop computers and smartphones. Another option is programming to access the device from the PC and copy files using a remote API (RAPI). Although these methods have completed tasks, it is not the best choice. Smartphone's built-in internet connection is better.
Retrieving remote data over the Internet is very simple on the SmartPhone device. In fact, if you have developed a Pocket PC application that retrieves data over the Internet, you already know all the needs. The easiest way to communicate with the remote server on Smartphone is Wininet function (HTTP or FTP), an XMLDOM API and Microsoft Internet browser that remotely loaded data (see Figure 2).
Figure 2. Retrieving remote data on SmartPhone
XMLDOM provides several data retrieval to Web developers. Use DOM you can retrieve data by two main methods: document objects and XMLHTTP objects LOAD methods. Both objects allow for data from the XML format on the remote web server. The biggest difference between the two is that the XMLHTTP object allows you to pass an XML object as part of the call, although the load command is not allowed. In the case where data is required to retrieve data, you should use the XMLHTTP object.
Whether you use that way you are in Xmldom, you only need to make a little change in your code. First you have to include the correct header file:
#include
Namespace MSXML
{
#include
}
#include
Objsafe.h and ocidl.h are must be required because they contain GUID descriptions, and the GUID is a pointer that works with COM must be. To enable COM to enter the MSXML analysis program, you must establish a MSXML name space and contain msxml.h. In addition, in order to compile the project, you should add OLE32.LIB and OleAut32.lib libraries to the connection program settings. Once the code uses XMLDOM, you can simply use the DomDocument's LOAD method to retrieve data from the remote server. This method only needs one URL that can be found and retrieved. It repeats a micro-regulatory control (Spinner Control) on the form in the document (Figure 3). After it is completed, it displays a message box that contains the entire XML document.
Msxml :: ixmldomdocument * ixmldoc = null;
Msxml :: ixmldomparseerror * pparsingerr = null;
Msxml :: ixmldomelement * ixmlelm = null;
MSXML :: ixmldomnodelist * ixmlchild = null;
MSXML :: ixmldomnode * ixmlitem = null;
Short tempty;
BSTR BSTR;
Variant vxmlsrc;
HRESULT HR;
Hwnd hlistbox;
Long LLENGTH;
HR = CoinitializeEx (null, coinit_multithread);
IF (! successded (hr)) Return 0;
HR = CocreateInstance (msxml :: CLSID_DOMDOCUMENT,
NULL, CLSCTX_INPROC_SERVER | CLSCTX_LOCAL_SERVER,
MSXML :: IID_ixmldomDocument, (lpvoid *) & iXmldoc);
IF (ixmldoc)
{
IXMLDOC-> PUT_ASYNC (Variant_false);
// Smartphone 2002 workspace:
// Delete Document Security Options
IOBJECTSAFETY * PSAFETY;
DWORD DWSUPPORTED, DWENABLED;
IF (ixmldoc-> queryinterface
IID_IOBJECTSAFETY, (VOID **) & psafety))))))))
{
Psafety-> GetInterfacesafetyOptions
Msxml :: IID_ixmldomDocument, & dwsupported, & dwenabled);
Psafety-> setInterfaceSafetyOptions
MSXML :: IID_ixmldomDocument, dwsupported, 0);
}
Variantinit (& VXMLSRC);
vxmlsrc.vt = vt_bstr;
IXMLDOC-> PUT_ASYNC (Variant_false);
vxmlsrc.bstrval = sysallocstring (l "http: / localhost /
SmartphoneArticleData.xml ");
HR = ixmldoc-> loading (vxmlsrc, & tempty);
Sysfreeestring (vxmlsrc.bstrval);
ixmldoc-> get_documentelement (& iXmlelm);
IXMLM-> SelectNodes (L "// Data / Status / S", & IXmlchild); // ixmlelm-> get_childnodes;
IXMLCHILD-> GET_LENGTH (& LLEngth);
HListbox = getdlgitem (hwnd, idc_listissues);
For (int x = 0; x
GET_ITEM (X, & IXmlitem);
IXMLITEM-> GET_TEXT (& BSTR);
SendMessage (Hlistbox, lb_addstring, 0, (lparam) BSTR);
}
// ixmlchild-> get_item (1, & ixmlitem);
IXMLDOC-> GET_XML (& BSTR);
MessageBox (NULL, BSTR, TEXT ("Article Demo"), MB_OK;
Figure 3. XML LOAD method example
Locally store data
After retrieving data to SmartPhone, the next step is to study the method of locally store data locally on the device. One option is not saved at all. You can retrieve data, perform some operations, then release data from memory. Unfortunately, in most cases, it is not so simple, so you have to decide to fit the application's format. You may save data to file storage (eg, flash card), or save it in local data storage (eg, CEDB).
For most commercial applications, you need to save your data in the file system. Although the data can be written to the RAM file system, it is not recommended because all data will be lost when the device is turned off or powered down. For ongoing memory, the SmartPhone device provides a flash file system as an IPSM memory control. Spaces are limited spaced over most SmartPhone, but many devices include a memory card slot that allows the use of removable memory cards.
Programming determines where storage data on Smartphone is very simple, thank you for your development of some APIs familiar with the development of the WINDOWS CE platform. These calls can be found in the Windows Shell API document. Now I will focus on the ShgetspecialFolderPath function. This function allows you to access the main SMARTPHONE file system and retrieve the complete path at runtime. After retrieving the path, you can use the path to store data related to the application. This function requires a CSIDL_ constant as an input parameter. These constants reflect a common folder in the SmartPhone operating system (application data, favorites, programs, starts, etc.). Because these public areas may provide a unique system ID to identify these directories on different devices. Recommended client applications Save data in subdirectory of CSIDL_Appdata returns to the directory. E.g:
#ifdef csidl_Appdata
IF (! SHGETSPECIALFOLDERPATH (NULL, SZFOLDERPATH, CSIDL_APPDATA, TRUE)
{
Assert (false);
HR = HRESULT_FROM_WIN32 (GetLastError ());
}
#ELSE
// Pocket PC does not have this definition to read the directory in the root.
/ / Maybe there will be some changes in the future, but the code can still work.
_TCSCPY (SZFolderPath, Text ("//"));
#ENDIF
I have said ago, some devices need additional memory cards. Unlike your desktop computer's hard drive, SmartPhone does not assign drive symbols for the memory card. Instead, the operating system establishes a directory in the root directory to express different parts of each memory card. In order to access different cards in a device, use the FindFirstFlashCard and FindNextFlashcard functions. If the memory card is found, FindFirstFlashcard returns a handle and pointer to the first block of memory card. If the handle is correct, you can pass it to findnextflashcard, which will return the next memory card's pointer and a BOOL value to indicate whether the search is successful. Once you find the memory card you want to use, the next step is to find a location to store data. The SHGETDocumentsFolder function is usually used when the document on the access device is accessed. It can be used for new or original memory cards. Here is an example of using ShgetDocumentsFolder:
Tchar szdocpath [250];
IF (! ShgetDocumentsfolder (l "//", szdocpath)))
MessageBox (Null, L "Retrieveing Path Failure", L "Call Failure", MB_OK; ELSE
MessageBox (NULL, SZDOCPATH, L "Documents Folder Path", MB_OK);
Simulator notes: Smartphone simulator does not support memory cards. It also does not support real memory cards attached to the PC running the simulator.
Database operation
For almost all commercial applications, it is necessary to save data to a local database, which is also true for many Smartphone applications. Compared with Windows CE and PCKET PC, the selection of databases on SmartPhone is only different. For the first SmartPhone version Smartphone 2002, only the local Windows CE database is supported, which does not support SQL Server CE or Pocket Access. In addition, the only option to access the Windows CE database is to use the database API contained in Windows CE 3.0. However, the code that accesses the Windows CE database is almost the same as the code written by the Windows CE device.
Synchronous Data
After using the connection and processes the data, the next step is to synchronize with the remote data storage. Because I have already introduced the use of xmldom to retrieve data over the Internet, I will continue to use this model and change the change over the remote server via the XMLHTTP object.
Before using the details of XMLHTTP, let's take a look at how SmartPhone uses web services. Currently, there is no internal library or component on the SmartPhone platform to provide SOAP client features. But SmartPhone's SOAP client is not outside possible because Smartphone 2002 SDK supports all possible components. If you need a SOAP client on SmartPhone, I suggest to view third-party libraries, which may be ported to Smartphone without much problem. In addition, you should remember that once the .NET concise framework component on Smartphone can be used, you can use the SmartPhone client.
The first step from SmartPhone to remote data storage synchronization data is to retrieve all changes in the main memory and convert to XML format. After completing, instantiate the XMLHTTP object and pass the data to a specific URL of the processing synchronization.
It is said that the XMLHTTP object has the ability to send messages to the remote server using XML format, which will be used here. The XMLHTTP object is another object available in the MSXML library included in the previous item. Figure 4 is the use of the object. It is easy to use, and an object is created from the IXMLHTTPRequest interface. In addition, establish a variant to keep the IXmldomDocument object. In order to pass this complex type, Variant must be set via vt_dispatch type. The remaining step is to call the Open and Send methods of the XMLHTTP object. Msxml :: ixmldomdocument * ixmldoc = null;
Msxml :: ixmlhttprequest * ixmlhttp = null;
HRESULT HR;
BSTR BSTR = NULL;
Variant VuserId;
Variant vPassword;
Variant VPassValue;
Variant vasync;
Short tempty;
HR = CoinitializeEx (null, coinit_multithread);
IF (! successded (hr)) Return 0;
HR = CocreateInstance (MSXML :: CLSID_DOMDocument, NULL,
CLSCTX_INPROC_SERVER | CLSCTX_LOCAL_SERVER,
MSXML :: IID_ixmldomDocument, (lpvoid *) & iXmldoc);
IF (ixmldoc)
{
IXMLDOC-> PUT_ASYNC (Variant_false);
// Smartphone 2002 workspace:
// Delete Document Security Options
IOBJECTSAFETY * PSAFETY;
DWORD DWSUPPORTED, DWENABLED;
IF (ixmldoc-> queryinterface (IID_IOBJECTSAFETY,
(void **) & psafety))))))))))))
{
Psafety-> GetInterfacesafetyOptions
Msxml :: IID_ixmldomDocument, & dwsupported, & dwenabled);
Psafety-> setInterfaceSafetyOptions
MSXML :: IID_ixmldomDocument, dwsupported, 0);
}
IXMLDOC-> PUT_ASYNC (Variant_false);
Ixmldoc-> loadingXML (L "
Joe
Smith
", & Tempty);
}
Variantinit (& Vasync);
Vasync.vt = vt_bool;
Vasync.BOOLVAL = FALSE;
Variantinit (& VUSERID);
Vuserid.vt = vt_bstr;
Vuserid.bstrval = l ""
Variantinit (& VPassword);
vPassword.vt = vt_bstr;
VPassword.bstrval = l ""
VariantInit (& vpassvalue);
VPassValue.vt = vt_dispatch;
VPassValue.pdispval = ixmldoc;
HR = CoinitializeEx (null, coinit_multithread);
IF (! successded (hr)) Return 0;
HR = CocreateInstance (MSXML :: CLSID_XMLHTTPREQUEST, NULL,
CLSCTX_INPROC_SERVER | CLSCTX_LOCAL_SERVER,
MSXML :: IID_IXMLHTTPREQUEST, (LPVOID *) & IXMLHTTP);
IXmlhttp-> Open (l "get", l "http://localhost/smartphonesavetest.asp",
Vasync, vuserid, vpassword;
hr = ixmlhttp-> send (vPassvalue);
IXMLHTTP-> GET_RESPONSETEXT (& BSTR);
Figure 4 XMLHTTP example
Access phone characteristics
Through Windows CE API, developers can simply add phone functions to the application. Similar to automatic dialing, interacting with calling logs, accessing the SIM card, sending, and receiving SMS messages, etc., can be simply added to the application. For normal work, most technical APIs need real devices or GSM wireless devices to the simulator, so if you plan to develop these types of features, you are ready to test real devices.
One of the simplest examples of telephone characteristics is to establish a voice call in the application. Because we have auxiliary TAPI that is released with Smartphone, only one line of code. All needs to be made in the code containing the ASTDTAPI.H file, add cellcore.lib in the connection program setting, and call the TapireQuestMakeCall function:
TCHAR SZDEFAULTNUM [] = text (" 1 (555) 555-5555");
Long LRESULT;
Lresult = TapirequestmakeCall ((LPTSTR) SZDEFAULTNUM, NULL, NULL, NULL
Return True;
It is also very simple to send SMS messages. With an auxiliary TAPI, you only need to add a file reference (SMS.H) in your code, add a library (SMS.LIB) in the connection program setting. The first step of sending or receiving a message is to call the SMSOpen function, the next initialization source and destination address, and then call the SMSsendMessage function. The final step is to call the SMSClose function to clear the established SMS_HANDLE. The code is shown in Figure 5.
SMS_HANDLE SMSHHANDLE;
SMS_ADDRESS SMSASOSOURCE;
SMS_ADDRESS SMSADESTINATION;
TEXT_PROVIDER_SPECIFIC_DATA TPSD;
SMS_MESSAGE_ID SMSMIDMESSAGEID;
/ / Try to open an SMS handle
IF (Failed (SMS_MSGTYPE_TEXT, SMS_MODE_SEND, & SMSHHHHHHHHHHHHHANDE, NULL)))
{
MessageBox (Null, L "Call to smsopen failed.", L "error", MB_OK |
MB_ICONERROR);
Return;
}
// set the source address
IF (! Busesefaultsmsc)
{
SMSASOSOURCE.SMSATADDRESSTYPE = SMSAT_INTERNATIONAL
_TCSNCPY (SMSASource.PTSADDRESS, LPSZSMSC, SMS_MAX_ADDRESS_LENGTH);
}
// Establish a target address
SMSADESTINATION.SMSATADDRESSTYPE = SMSAT_INTERNATIONAL
_TCSNCPY (SMSADESTINATION.PTSADDRESS, LPSZRECIPIENT, SMS_MAX_ADDRESS_LENGTH); // Establish a provider specific data
Tpsd.dwmessageOptions = bsendconfirmation? ps_message_option_statusreport
: PS_MESSAGE_OPTION_NONE;
Tpsd.psMessageClass = PS_MESSAGE_CLASS1;
Tpsd.psreplaceOption = psro_none;
// Send a message, display source or failure
IF (SUCCEEDED (SMSSendMessage ((busefaultsmsc)? NULL:
& smsasource,
& SMSADESTINATION, NULL, (PBYTE) LPSZMESSAGE,
_TCSLEN (LPSZMESSAGE) * SIZEOF (TCHAR), (Pbyte) & TPSD,
SIZEOF (Text_Provider_Specific_Data), SMSDE_OPTIMAL,
SMS_OPTION_DELIVERY_NONE, & SMSMIDMESSAGEID))))))
{
MessageBox (Null, L "Message Sent", L "Success", MB_OK;
}
Else
{
MessageBox (Null, L "smssendmessage failed", l "error", MB_OK |
MB_ICONERROR);
}
// Clear
Verify (Succeeded));
Figure 5. SMS code example
It also provides more APIs, I only introduced several basic. With these capabilities, mobile apps have greatly expanded on the basis. For example, automatic calls or messages can be triggered when a specific event occurs in the application.
in conclusion
This article I discussed some foundations for establishing the real smartphone app. You can see this type of SmartPhone application is very striking in the field of corporate calculations.
Author:
Tao Gang
source:
Sidi Net
Http://www.biplip.com/default.aspx?tabid=34&mid=348&ctl=view&ict=281
