API calls to Windows Mobile

Making calls to API in Windows Mobile is lot easier compared to other platforms such as Symbian etc, but we need to take care of few aspects mentioned below.

• Since the parameters sent to the API are not user friendly, developers need to have some device level knowledge
• Since all APIs that the developers need might not be exposed in a single DLL, the DLL name will have to be specifically mentioned. DLL name where the API exists has to be hardcoded while instantiating the API method
  
  Below is an example emphasizing this. In the example, the input mode of a Text box control is set at runtime. The APIs which are used are:
• GetCapture: Retrieves the handle of control which is currently active
• GetWindow: Child window is retrieved for given handle
• SendMessage: Any operation can be performed by sending a message using current handle, appropriate modes. This API is generally used for setting the input mode of any input controls (e.g. textbox control)
  
  The API call in C# can be as below.
  [DllImport("coredll.dll", EntryPoint="GetCapture")]
  private static extern IntPtr GetCapture();
  
  Note: Above code has to be repeated for other two APIs. Windows CE (the operating system Windows Mobile is based upon) aims to have a Win32 API implementation which is fairly compatible with the implementation found in desktop versions of the Microsoft Windows operating system. However, for a number of technical and historical reasons the APIs are commonly exposed by different DLLs. This leads to a potential issue since the DLLImport attribute utilized to Platform Invoke a function requires hard coding the DLL’s name into your application.
  
  Next step involves setting the input mode of the given control.
  The function should do the following operations in the order given below:
• Retrieve the handle for the control by using the GetCapture API
• Retrieve child window (.NET Compact Framework text box using Spy refers to the real text box as a “Child window”) using GetWindow API
• Send the message to the child handle to set the input mode using SendMessage API
  
  Definition of “InputMode” is given below:
  public enum InputMode
  {
  Spell = 0,
  T9 = 1,
  Numbers = 2,
  Text = 3
  }
  
  Warning: The use of handles (hWnds) from within the .NET Compact Framework is not supported and should be thoroughly tested within your application. Due to the way the runtime internally manages hWnds, the use of hWnds may not work with future releases or could break your code if you do a lot of manipulation with them. And note that the class uses Interop to call a few native APIs.
  
  If you find any other easy way to call APIs then please let me know
  
  To summarize, “Why making calls to APIs in Windows Mobile is lot easier compared to other platforms?”
• Implementation of API calls in other platforms is not as straightforward as it is in Windows Mobile. There are many steps involved and developers should have a thorough background of the same.
• In other platforms, we cannot write Managed code as it is not supported

Location Based Services

Location Based services (LBS) are not new to mobile services. Having been around since 2001, it’s a pretty long time. The arrival of powerful mobiles coupled with reduced data charges, broadband, social networking, instant messaging, maps, mash-ups has changed the scene. One can now easily browse the net with these devices and it brings to the device a whole lot of services that the user can choose and consume. This gives a tremendous boost to LBS.

LBS require the handset to be GPS aware. Nowadays, most handsets come with GPS facility. With the help of GPS, one would be in a position to locate information specific to the location of the user. For example, he would be able to find out the location of the nearest ATM, theatres, restaurants, shopping complexes, discounted deals and even the weather forecast. Not just that, if coupled with social networking, one would be able to discover the location of their friends if they are in the vicinity of the user!! All this magic could be accomplished without the user entering his current location zip code as input. At the application layer side, the service applications would be able to map the GPS location to the zip code and deliver the content the user asked for.

LBS even finds application in the delivery tracking, where one would be able to track the shipment as it leaves the warehouse and ultimately delivered to the user. With the help of active RF, we could still track the shipment in situations where the GPS would not work.
What’s more, business networking, making contacts could benefit largely from these services. Even targeted direct advertising can significantly alter the marketing landscape and bring more value for money.


GPS Handsets
In terms of handset manufacturers, Nokia leads the pack with handsets that are GPS enabled. GPS support has become a staple in their N-Series Symbian devices and E-Series handsets. Nokia have driven users to take advantage of that hardware by releasing a couple of free LBS applications for S60 users, both of which have been hugely successful. Nokia Maps, which was originally a free add-on and now comes pre-installed every Nokia S60 handset, and Nokia Sports Tracker has been downloaded by millions of users.
Apple has not been left out and their hugely successful iPhone had a location tracking software in a firmware update for the original iPhone which identified the user’s location using cell towers and WiFi hotspots. This trend continued when they added Assisted-GPS to the iPhone 3G.

Building location aware applications
The iPhone SDK allows users to build applications that are location aware. Google’s Android platform also has LBS as one of the core components. You can explore this post for more on LBS in Android. Similarly, for Nokia handsets, you can use the S60 SDK. All of these SDKs have location APIs along with various parameters that you can easily program in your application.
For installing the applications, it needs to be setup so that it can be downloaded from the web. The handset would need to point to this website and download the application.

Emerging Markets – the untapped market
In emerging markets, many people have turned to access the Internet with their mobile phone in the past year as falling costs, increased bandwidths and improvements in browser technology have made it quicker to surf from a cell phone. For many, browsing on a handheld device is a cheaper alternative to buying a PC or paying for home Internet service. The enormous potential of this cannot be underestimated. China, India and other emerging markets are perfectly poised in terms of tapping the LBS market. The rollout of 3G services in India also promises to revolutionize the way we look at the mobile and join the gang in harnessing the power of location based services.

Cellular Generations and Communications

Wireless phone standards have a life of their own. Anybody can tell, because they're spoken of reverently in terms of generations. There's great-granddad who's pioneering story pre-dates cellular, grandma and grandpa analog cellular, mom and dad digital cellular, 3G wireless just starting to make a place for itself in the world, and the new baby on the way, 4G.

Below is the demarcation for several specifications for these generations …….

click on image to get better view of image

GPRS : Generalized Packet Radio Service
UMTS : Universal Mobile Telecommunication Systems
EDGE : Enhanced Data GSM Evolution
UMB : Ultra Mobile Broadband
LTE : Long Term Evolution
GSM : Global System for Mobile communication
CDMA : Code Division Multiple Access
TDMA : Time Division Multiple Access
WDMA : Wavelength division Multiple Access
OFDMA : Orthogonal frequency division Multiple Access
3GPP : 3rd Generation partnership project

1G Mobile Device

2G Mobile Device

3G Mobile Device

More on 3G in next posting ……………..

Future of iPhone

Did you know

• iPhone is used 66% of the time by people browsing the Web with their phone. Second place was JavaME at 9% share.


• Apple sold 4 million Iphones in 2007 & 13.4 million in 2008


• iPhone with 31% market share ranks as the top handset & smart phone in Western Europe


• The Apple AppStore had more than 500 million applications downloads in its first six months of service.
  
  Despite all these great numbers and facts, there are predictions that Google’s Android phones will surpass iPhone by 2012. Nokia’s Symbian OS will be the leading player in the market, which is believable as Nokia continued to lead the mobile phone market with a 37.7 market share in 2008. People are leaning more towards using their Mobile phones instead of their laptops. If you look at the trend in 2008 itself, people bought more smart phones than notebooks. Symbian needs to move to Open Source very soon, in order to continue the lead. Else more and more people will use Android for the ease of programming. Will Apple do some magic ?
  
  Sources: Information Week , Channelweb and others

Mobile Everywhere

Mobile Application Architecture Series – Design Considerations

Mobile applications inherit various challenges which need to be considered while designing on any platform (Microsoft / Symbian / OS X etc). The following section tries to address various design guidelines for a mobile application development. Technology stack considerations would be the next in this series of blogs.
A mobile application will normally be a multi-layered application comprising user experience, business and data layers. When developing a mobile application, you may choose to develop a Thin-Client or Rich-Client. If you are building a rich client, the business and data layers will be located on the device itself. In Thin-Client, the business and data layers will be located on the server.

Design Considerations:
Follow these design guidelines to ensure that the application meets your requirements and performs efficiently in mobile world.

1) Thin-Client or Rich-Client or RIA. If your application requires local processing and must work in an occasionally connected scenario, consider designing a Smart (thin) client. But, a Rich-Client application will be more complex to install and maintain. If the application can depend on server processing and will always be fully connected, consider designing a Thin-Client. If your application has a rich user interface, only limited access to local resources, and portability to other platforms is required, then RIA would be a good choice (eg. ETrade).

2) Device Types to Support: While choosing which device types to support, consider screen size, screen resolution (DPI), CPU performance characteristics, available memory and storage space (inbuilt & external) and Integrated Development Tool availability. On top of the above, we need to consider the User Requirements and Organizational Constraints / Guidelines. Any additional components such as GPS and Integrated Camera may influence your choice of application type and device type.

3) Connectivity: The real time connectivity requirement between the mobile device and Gateway would highly influence the decision of whether to go for Thin-Client or Rich-Client or RIA. If an application requires an intermittent network connection, our design approach should properly handle caching, state management and data access mechanisms.

4) UI design considerations: Mobile devices requires simple UI in order to work within the constraints imposed by the device hardware such as memory, battery life, different screen sizes and their orientations and network bandwidth.

5) Layered Architecture: Depending on the application type, multiple layers may be located on the device. Use the concept of Layers to maximize the separation of concerns, and to improve reuse and maintainability for your mobile application. However, aim to achieve the smallest footprint on the device by simplifying your design compared to a desktop or web application.

6) Security: Designing an effective authentication and authorization strategy is important for the security and reliability of your application. Mobile devices are usually designed to be single-user devices and normally lack basic user profile and security tracking beyond just a single password. Mobile applications can also be especially challenging due to connectivity interruptions.

7) Caching: Use caching to improve the performance and responsiveness of your application, and to support operation when there is no network connection. Use caching to optimize reference data lookups, and to avoid network round trips. When deciding what data to cache, consider the limited resources of the device; you will have less memory available than a PC.

8) Communication: Device communication includes wireless communication (over the air) and wired communication with a host PC, as well as more specialized communication such as Bluetooth or Infrared Data Association (IDA). When communicating over the air, consider data security to protect sensitive data from theft or tampering.

9) Performance Considerations:
a. Design configurable options to allow the maximum use of device capabilities. Allow users to turn off features they do not require in order to save power.
b. To optimize for device resource constraints, consider using lazy initialization.
c. Optimize the application to use the minimum amount of memory. When memory is low, the system may release cached intermediate language (IL) code to reduce its own memory footprint, return to interpreted mode, and thus slow overall execution.
d. Consider using programming shortcuts as opposed to following pure programming best practices that can inflate the code size and memory consumption. This decision should be a thoughtful one as it may contradict the design principles of OOPS and maintainability.
e. Consider power consumption when using the device CPU, wireless communication, or screen while on battery power. We should balance power consumption with performance.

In my view, the above listed considerations are only a subset of complete list, but tried to address the key areas in it. One basic design approach for most of the mobile applications is “avoid BDUF”, Big Design Up Front, which recommends design evolving over time and avoid making a large design effort prematurely.