Thursday, 27 September 2012

How to implement Sending a SMS Message from an Android Application


Introduction

We often come across situations where we are required to send a text message from our Android app. In this article we will explore all possible ways to achieve this simple yet very useful task.

Background

There are two possible ways to send a text message from an Android app
1. The first way is to send it programmatically from your application.
2. The second way is to send it by invoking the built-in SMS application.

In this article we will explore both the scenarios one by one.

* If you are new to Android app development, do refer to the Demo Project section of this article for some useful tips.

1. Sending a SMS programmatically from your application

Include the following permission in your AndroidManifest.xml file -
<uses-permission android:name="android.permission.SEND_SMS" />


Import the package -
import android.telephony.SmsManager;

Code to send a SMS -

public void sendSMS() {
    String phoneNumber = "0123456789";
    String message = "Hello World!";

    SmsManager smsManager = SmsManager.getDefault();
    smsManager.sendTextMessage(phoneNumber, null, message, null, null);
}
The method sendTextMessage of class SmsManager sends a text based SMS.





Method Detail
public void sendTextMessage(String destinationAddress, String scAddress, String text, PendingIntent sentIntent, PendingIntent deliveryIntent)
Details about the parameters that the method accepts can be found here.
If you use the code above you will able to send messages with length less than or equal to 160 characters only.

Code to send a long SMS -

public void sendLongSMS() {
 
    String phoneNumber = "0123456789";
    String message = "Hello World! Now we are going to demonstrate " + 
            "how to send a message with more than 160 characters from your Android application.";

    SmsManager smsManager = SmsManager.getDefault();
    ArrayList<String> parts = smsManager.divideMessage(message); 
    smsManager.sendMultipartTextMessage(phoneNumber, null, parts, null, null);
}
The method sendMultipartTextMessage of class SmsManager sends a multi-part text based SMS


Method Detail
public void sendMultipartTextMessage(String destinationAddress, String scAddress, ArrayList<String> parts, ArrayList<PendingIntent> sentIntents, ArrayList<PendingIntent> deliveryIntents)
Details about the parameters that the method accepts can be found here



Note
The method divideMessage of class SmsManager divides the message text into several smaller fragments of size 160 characters or less.

* Refer to the Points of Interest section of this article for a useful tip.

2. Send a SMS by invoking the built-in SMS application using Intents.

To invoke the SMS application via intents we have to do the following:
- Set the action to ACTION_VIEW
- Set the mime type to vnd.android-dir/mms-sms
- Add the text to send by adding an extra String with the key sms_body
- Add the phone number of the recipient to whom you wish to send the message by adding an extra String with the key address

Note:
- The last two steps are optional, if you don't wish to specify the message text or the recipients you can ignore these steps.
- If you wish to set multiple recipients use semi-colon ';' as the separator in the string passed as theaddress

Code to send a SMS using Intents

    
public void invokeSMSApp() {
        Intent smsIntent = new Intent(Intent.ACTION_VIEW);

        smsIntent.putExtra("sms_body", "Hello World!"); 
        smsIntent.putExtra("address", "0123456789");
        smsIntent.setType("vnd.android-dir/mms-sms");

        startActivity(smsIntent);
}

Points of Interest

If you choose to send messages programmatically and wish to add the message sent from your application in the native 'Messages' application of Android in the 'Sent' folder, here is the code to achieve it using Content providers -

Code to save a SMS in 'Sent' folder of native 'Messages' application

Include the following permission in your AndroidManifest.xml file -
<uses-permission android:name="android.permission.WRITE_SMS" />
<uses-permission android:name="android.permission.READ_SMS" />
You will have to add both WRITE_SMS and READ_SMS permissions.

Add the following imports -
    import android.net.Uri;
    import android.content.ContentValues;

Insert the below code where you wish to perform the operation -
    ContentValues values = new ContentValues(); 
              
    values.put("address", "0123456789"); 
              
    values.put("body", "Hello World!"); 
              
    getContentResolver().insert(Uri.parse("content://sms/sent"), values);

Demo Project

This is a demo project which implements all the scenarios as discussed in this article.

It has used EditText widget for the Phone Number and Message input. Here I'd like to mention twoXML attributes that I have used -
  • android:hint This string is displayed as a hint to the user when the field is empty. This will give your application a more native look and feel.
  • android:inputType="phone" (for Phone Number field) This signals the input method (IME) that this field should accept only valid Phone Numbers. This will save you from validating user input.

Which way to go....

Both the ways have their own set of pros and cons. If you decide to use Intents to send text messages from your application then no additional permissions are required but it will become a two step process, for instance if the user presses any button in your app to send SMS the intent will be displayed where he/she will have to press send; whereas if you decide to do it programitically you might also have to check for the result.


Friday, 24 August 2012

Check out these Secret codes for Android Mobile Phones:

Check out these Secret codes for Android Mobile Phones:

1. Complete Information About your Phone

*#*#4636#*#*
This code can be used to get some interesting information about your phone and battery.

Usage statistics

2. Factory data reset
*#*#7780#*#*
This code can be used for a factory data reset. It'll remove following things:
Google account settings stored in your phone
System and application data and settings
Downloaded applications
It'll NOT remove:
Current system software and bundled application
SD card files e.g. photos, music files, etc.
Note: Once you give this code, you get a prompt screen asking you to click on "Reset phone" button. So you get a chance to cancel your operation.

3. Format Android Phone

*2767*3855#
Think before you give this code. This code is used for factory format. It'll remove all files and settings including the internal memory storage. It'll also reinstall the phone firmware.
Note: Once you give this code, there is no way to cancel the operation unless you remove the battery from the phone. So think twice before giving this code.

4. Phone Camera Update

*#*#34971539#*#*
This code is used to get information about phone camera. It shows following 4 menus:
Update camera firmware in image (Don't try this option)
Update camera firmware in SD card
Get camera firmware version
Get firmware update count
WARNING: Never use the first option otherwise your phone camera will stop working and you'll need to take your phone to service center to reinstall camera firmware.

5. End Call/Power

*#*#7594#*#*
This one is my favorite one. This code can be used to change the "End Call / Power" button action in your phone. Be default, if you long press the button, it shows a screen asking you to select any option from Silent mode, AirPlane mode and Power off.
You can change this action using this code. You can enable direct power off on this button so you don't need to waste your time in selecting the option.

6. File Copy for Creating Backup

*#*#273283*255*663282*#*#*

This code opens a File copy screen where you can backup your media files e.g. Images, Sound, Video and Voice memo.

7. Service Mode

*#*#197328640#*#*
This code can be used to enter into Service mode. You can run various tests and change settings in the service mode.

8. WLAN, GPS and Bluetooth Test Codes:

*#*#232339#*#* OR *#*#526#*#* OR *#*#528#*#* - WLAN test (Use "Menu" button to start various tests)

*#*#232338#*#* - Shows WiFi MAC address

*#*#1472365#*#* - GPS test

*#*#1575#*#* - Another GPS test

*#*#232331#*#* - Bluetooth test

*#*#232337#*# - Shows Bluetooth device address

9. Codes to get Firmware version information:

*#*#4986*2650468#*#* - PDA, Phone, H/W, RFCallDate

*#*#1234#*#* - PDA and Phone

*#*#1111#*#* - FTA SW Version

*#*#2222#*#* - FTA HW Version

*#*#44336#*#* - PDA, Phone, CSC, Build Time, Changelist number

10. Codes to launch various Factory Tests:

*#*#0283#*#* - Packet Loopback

*#*#0*#*#* - LCD test

*#*#0673#*#* OR *#*#0289#*#* - Melody test

*#*#0842#*#* - Device test (Vibration test and BackLight test)

*#*#2663#*#* - Touch screen version

*#*#2664#*#* - Touch screen test

*#*#0588#*#* - Proximity sensor test

*#*#3264#*#* - RAM version


Original Article: http://www.linkedin.com/groupItem?type=member&_mSplash=1&qid=0fe49ac8-6087-49b7-a6f0-73f51a28afd2&trk=group_featured_list-0-b-ttl&goback=%2Egmr_4494529%2Egfl_4494529&item=125931482&gid=4494529&view

Friday, 17 August 2012

How Developers Really Feel About Working With iOS And Android

Vision Mobile, a market analyst firm, recently surveyed more than 1,500 mobile developers worldwide to put together a report on the state of the app economy in 2012. Here are some interesting findings that will give you a better idea of where the market is right now, and where it may be headed in the future. From Business Week:













If you want to check out more graphs hit the link:
http://www.businessinsider.com/the-state-of-the-app-economy-in-2012-2012-6#

Mobile Content: Usage & Expectations

It has been noted a lot of time and I’m sure it will be brought up again and again. It is so so important for mobile Developers and Marketers to get to grips with the fact that Mobile users are not Patient or forgiving . Mobile users expect your site to work just as well on their phones as if they were sitting in front of a computer. So make sure you get it right. You have been warned :)

 

Tuesday, 7 August 2012

Is HTML5 the Answer in Mobile App Development ?

2 posts in 1 day I know but I feel there is still some information developers and companies are looking for to why they should be using HTML5, I hope this helps...

In the mobile app development industry, there continues to be a lot of debate about whether to use HTML5, adopt a hybrid standard, or go native. With the support of heavyweights like Amazon and Facebook, it seems that HTML5 is due for mass adoption. However, there are still some issues that need to be resolved.

The concept behind HTML5 offers a strong selling point: “write once, run anywhere.” This idea has been the goal of many developers since the launch of Java. There have been many standards introduced since then, but none has fit the “write once, run anywhere” ideal. As an open standard that offers numerous benefits, HTML5 seems to best fit industry requirements.

Why HTML5 Works

In any organization as well as in the general marketplace, there are various mobile devices that have to be supported. Apple runs its own unique operating system — iOS, and even the Android, which is already an open standard, suffers from fragmentation. The hardware and software for each device also have unique configurations—which means that dedicated native applications must be created from scratch to work seamlessly on devices. All these customized versions of a single mobile app involve time, money, and inconvenience. HTML5 offers a viable alternative.

HTML5 can run on iPhone, Android, or BlackBerry devices. It also has CSS3 features that allow automatic page layout adjustments across a vast number of form factors. Because it is delivered as a mobile web app, an HTML5 app can bypass the application approval process to be put in various application stores. It can provide functionality to the application server immediately with increased efficiencies, especially in an enterprise setting. Existing code can be leveraged to develop additional features, and the acceptance barrier is lowered when it comes to adoption at every level in the organization.

Side Effects of HTML5

It is important to remember that enterprise users are also mainstream consumers. Thus, they have high expectations of how mobile apps should look and perform. HTML5, while providing significant enterprise benefits, cannot compete with native applications. Native apps are tailor-made solutions for specific devices, so they offer a better user experience. Another possible downside to using HTML5 is its poor functionality when it comes to letting users access and store data on their mobile devices. However, some developers are opting for a hybrid approach, using HTML5 to build the application within a native shell.  This eliminates some of the downsides of a pure HTML5 alternative (app-store, storage, etc.).  The Facebook application, for example, is built almost entirely in HTML5, but runs natively on the device.

There are pros and cons to using HTML5 in your organization. It doesn’t offer a one-size-fits-all solution. Its availability alone, though, offers glimpses of what developers can do in the future as they leverage HTML5 to varying degrees and create pure, native, and hybrid mobile apps.

The 10 Top Best Practices of Mobile Testing

There are many things to consider when testing on a mobile platform, and it can be somewhat overwhelming, especially if you are new to mobile platform testing.  Mobile application testing is the same as testing Web applications, just on a smaller form factor, right?  Wrong.  While it is true that some basics of testing best practices apply, there are many nuances to consider that are specific to the mobile platform.  The following list is not all-inclusive; instead, it is meant to provide some fundamental guidelines to follow when testing on a mobile platform.
 
1.Ensure the test objectives align with the corporate/business requirements.  Ask the following questions:
•For functionality, how important is it that the content be correct?
•How should content be displayed on different form factors if the device is smaller or larger than the baseline design?  What is the expected result if content is cut off or if there is too much whitespace?
•How should the content display in portrait mode vs. landscape?
•How should the application behave depending on the connection type?  For example, Wi-Fi vs. cellular
•What are the requirements for the user experience?  Is performance important?  For example, the amount of time it takes to log in.
 
2.Don’t test everything.  When you take into consideration device type, operating system, carrier, and so on, there are thousands of permutations. Keep in mind that you don’t want to test all of them as initial testing plus subsequent regression tests across every combination is both time and cost intensive. Instead, use analytics to determine the top 10-20 combinations, and then set up your test environment to align with what the end-users use most often.
 
3.Build, configure, and maintain a proper mobile test lab.  If you are restricting your testing to manual only, you might consider a cloud provider to limit expenses.  However, if you are pursuing automation or have security concerns about exposing your QA environment to a cloud, an on-premise lab might be a better option.  As long as you limit your focus to the top device combinations that your customers actually use, managing and maintaining an on-premise lab is relatively easy.
 
4.Remember to plan for integration testing.  If your desktop Web site connects to the same backend as your mobile site, you will need to create test cases that perform functions on both.  For example, consider  the following test case:
•Log in using Internet Explorer, add an item to your cart on a shopping site.
•Access that same site on an iPhone and confirm the items shown in your cart matches. those placed there using your Internet Explorer browser.
•Place an order for the item using the iPhone browser.
•Log in using Internet Explorer and confirm the order was placed correctly.
 
5.Don’t be tempted to use emulators or simulators.  While they may seem like a good way to cut lab expenses, it has been proven that defects are missed and consistently leak into production when testing using emulators or simulators.  All system testing must be done on real devices to ensure proper test integrity.  After all, your customers are not going to use an emulator when they use your app, are they?
 
6.Plan for rapid change.  The release cycles for mobile applications take an average of one to four weeks, so plan to optimize your resources to deal with shortened timelines.
 
7.Use remote control tools.  There are tools available that enable you to view and control real mobile devices, similar to the way Remote Desktop works for PCs, making life a bit easier for testers.  Some of these tools are free while others carry a small fee, depending on the target platform.  Remote control tools are especially useful for today’s touchscreen smartphones, allowing use of a mouse in place of a tester’s finger to perform gestures (taps, swipes, etc.) and a desktop keyboard in place of the device’s virtual keyboard.  This is very practical and efficient for manual testing, by eliminating mis-taps, for example, as well as allowing the tester to take screenshots or record video to share defects with developers.  This is a requirement for automation on real devices because all automation tools reside there.
 
8.Choose the level of test integrity you are comfortable with and stand behind it.  There are three primary methods to enable remote control of mobile devices: use of third party tools, use of hooks compiled into your application, or a combination of both.  There are pros and cons to each method and it can be difficult to determine which option is the best.  Selection of a method is a highly controversial subject, with testing leaders debating the level of integrity that is lost with either method.  You must choose the method or methods that best meet your organization’s needs, and then minimize any potential risks.  For more in-depth information about this topic, please read “Remote Control for Mobile Devices“.
 
9.Use test automation.  Evaluate available mobile test automation tools using criteria tailored to your organization’s needs.  Don’t get caught up in feature lists or record/playback demos!  A vendor with the most checkmarks on a feature list may not be the best fit for your organization’s business requirements.  For example, consider what it takes to update and maintain an automation script after it is written as part of the total cost of ownership. For more detail on test automation, download, “Mobile Application Test Automation“.
 
10.Adapt your approach to your methodology.  Adapt your testing approach to your development methodology. Are you Waterfall or Agile? Many of the decisions you make about using remote control tools, test lab setup, and even manual vs. automation testing, should be made with your company’s preferred development methodology in mind. Why? Because how your mobile app is developed impacts the feasibility of the testing approach that works best for your company.