===== Installing Super Duper Messaging Manager =====

1. Download the [[SDK|SDK]]

2. In a strings file in /res, add your SDSMS_ID:

<code java><string name="SDSMS_ID">com.yourpackage.name</string>
</code>

If you have a registration ID, enter it here. Otherwise, this can be anything you want it to be (or leave it alone). Setting it to a unique value is recommended because if it is the same as another app, your app may not function properly and may be denied access to SDMM features.

3. Determine the appropriate Access Type for your app based on these values as indicated here: [[Access Types|Access Types]]


4. Replace SmsManager wtih SDSmsManager anywhere you use it in your project. If you set it globally in an Application class, that will work too. For example replace:

<code java>SmsManager mSmsManager = SmsManager.getDefault();
</code>

with this:

<code java>SDSmsManager mSDSmsManager = SDSmsManager.getDefault(context, context.getString(R.string.SDSMS_ID),
      SDSmsManager.ACCESS_TYPE_MESSAGING);
</code>

5. Replace all SmsManager calls with SDSmsManager calls, like this:

<code java>	SDSmsManager sms = SDSmsManager.getDefault(context, context.getString(R.string.SDSMS_ID),
        		SDSmsManager.ACCESS_TYPE_MESSAGING);
	try {
		sms.sendTextMessage(phoneNumber, null, message, sentPI, deliveredPI);
	} catch (Exception e) {
		// error sending message, notify user and update database
	    		sendError(msgId, phoneNumber);
	}
</code>

6. If you use a SqliteWrapper, like many examples that are readily available, simply replace you import statement in those classes with the following:

<code java>import com.sdmmllc.superdupersmsmanager.database.sqlite.SqliteWrapper;
</code>

The included class does URI resolution normally except that the standard "sms" authority is replaced with the "sdsms" authority when SDMM is the Default Messaging App. 

Also included in the SDMM SqliteWrapper is the SDContentResolver class. This class simply checks to see if you URI should be converted to SDMM Uri's prior to being resolved. This can be used to Replace the standard ContentResolver class and will resolve "sms" related authorities appropriately. For example, if this is your code:

<code java>ContentResolver contentResolver = getContentResolver();

final String[] projection = new String[] { "retr_st", "date", "_id", "ct_t" };
Uri uri = Uri.parse("content://mms-sms/conversations");

Cursor cursor = contentResolver.query(uri, projection, null, null, "_id DESC");
</code>

Then that source code can be rewritten as follows and the "sdsms" authority will use the Super Duper Messaging Manager provider when it is the "Default SMS App" and it will use the standard "sms" authority when it is not:

<code java>SDContentResolver sdContentResolver = new SDContentResolver(context);

final String[] projection = new String[] { "retr_st", "date", "_id", "ct_t" };
Uri uri = Uri.parse("content://sdmms-sdsms/conversations");

Cursor cursor = sdContentResolver.query(uri, projection, null, null,"_id DESC");
</code>

This is a convenience method only. We do not require that you use SDContentResolver unless you are currently using the Android ContentResolver for querying SMS content.

Also, this class will make the appropriate registration calls to SDMM to ensure SDMM identifies and handles your app appropriately.

7. In some cases, you may reference Uri's from Telephony or even statically. All MmsSms Uri's need to originate from dynamic methods that are provided. For example to get the Sms.Inbox Uri replace the following:

<code java>Sms.Inbox.CONTENT_URI
</code>

with this code (and import SDSmsManager into any classes that do not already have it):

<code java>SDSmsManager.Sms.Inbox.CONTENT_URI()
</code>

As a side note, if you create or make static variable references to these Uri's, this **will not work** because the methods will only execute as the app is instantiated. If the user changes the default SMS app, then your app may not behave properly. These **must** be runtime/dynamic method references. If you use static or variable references your compiler will not complain but it will most likely result in runtime problems for users.

8. Implement the SDMM callback for received messages. This allows you to tell SDMM if your app attempted to abort the incoming SMS. Here is an example:

<code java>	private ISDSmsReceiveCallback.Stub mCallback = new ISDSmsReceiveCallback.Stub() {
		@Override
		public boolean onReceive(Intent intent) throws RemoteException {
			//
			// do stuff here to process the SMS message
			// in this example, we are trying to demonstrate that you could re-use
			// existing code but return the appropriate result for "abort"
			// 
			// true - abort broadcast
			//
			// false - your app did not abort the broadcast
			//
			SmsIntentReceiver receiver = new SmsIntentReceiver();
			return receiver.onReceive(intent);
		}
		
	};
</code>

In this example, the intent is processed and will be passed back to SDMM unless the callback returns a value of "true" - indicating that your app aborted the SMS broadcast.

9. **(New with SDK 0.95) - BETA Feature: SDMM is NOT the Default SMS App**

To try to use your app **without** SDMM as the default messaging app, you must do the following:

Remove your "abort" call if SDMM is installed. Only perform the SDMM "abort" if SDMM is not installed except on the SDMM Duplicate message. 

SDMM will send a duplicate SMS_RECEIVED message to your app. To properly abort a message, you should **not** abort the original message. In Android KitKat+, an app is **not** supposed to be able to abort the SMS_RECEIVED intent, but on some (or all) platforms it can. If it does, then SDMM will not receive any notice of the SMS_RECEIVED (but the Default SMS App **will** get the SMS_DELIVERED intent). This is not how the documentation says it should perform, so it may not do this on your test device.

To allow for appropriate processing, your app should **not** abort the SMS_RECEIVED intent. Then, SDMM will query your app with a duplicate SMS_RECEIVED intent and that intent should return the ABORT flag to SDMM as demonstrated here:

<java code>	String sdsmsDup = "";

		// look for this string for the duplicate SMS_RECEIVED broadcast
		if (intent.hasExtra(SDSmsConsts.SDSMS_DUPLICATE)) sdsmsDup = SDSmsConsts.SDSMS_DUPLICATE;

		// then check if the SMS_RECEIVED intent is an SDMM duplicate
		// then indicate the abort accordingly
		if (SDSmsConsts.SDSMS_DUPLICATE.equals(sdsmsDup)) {
			// this code will abort the message in SDMM
			//
			Log.i(TAG, "aborting intent for SDSMS");
			setResultCode(0);
			setResultData(SDSmsConsts.SDSMS_ABORT);
			intent.putExtra(abort, true);
			Log.i(TAG, "SDSmsManager found, duplicate intent signal for abort");

		} else if (!SDSmsManager.isSdsmsIntstalled()) {

			// insert your code to abort intent for non-KitKat+ devices
			//
			Log.i(TAG, "SDSmsManager not found, aborting message");
		}
</code>

This will appropriately signal SDMM to abort the SMS_RECEIVED intent. When SDMM is not the default, you should not abort the broadcast in order for SDMM to process the intent appropriately.

This is currently a **BETA** feature. Please test this since we do not have all devices available. Also, be aware that SDMM will attempt to dismiss any notifications related to the SMS. It my "roll" and the ticker message may be visible, but it should dismiss before being available in the notification drawer. However, we are working on improving the response time so that it will dismiss prior to even being displayed. It may be advisable to warn your users. (We are working on standard messaging for this.)