Reader Mobile SDK, Android, and data storage conclusion

Reader Mobile SDK, Android, and data storage conclusion

In our last post we talked about where Reader Mobile SDK for Android stores the data that it writes and mentioned that we would be adding some hooks to Reader Mobile SDK to allow application developers to decide where data for their application should be written. These hooks have since been finalized and will be available in an upcoming release of Reader Mobile SDK from Datalogics! We strongly encourage application developers to go back and update their apps to use these new hooks on Android.

What we added

In our upcoming release of Reader Mobile SDK we have defined two new extern functions in the dpdev::AndroidDevice class (this is the class that we recommend using instead of dpdev::UNIXDevice, hopefully you are already familiar with this class). If you are already using dpdev::AndroidDevice then you should already be familiar with the extern keyword because there are already three functions defined as extern within the dpdev::AndroidDevice class :

  • extern dp::String getDeviceNameAndroid();
  • extern dp::String getDeviceSerialAndroid();
  • extern dp::String getApplicationPrivateStorage();

The new extern functions added are as follows

  • extern dp::String getXMLFileStorage()
  • extern dp::String getFulfilledBookPath()

If you are using dpdev::AndroidDevice and you update your application to use Datalogics’ next Reader Mobile SDK release you will see some lovely compiler errors that indicate you need to implement these functions somewhere because they are not implemented in Reader Mobile SDK! In order to solve these compiler errors you just need to go and implement these functions somewhere in your Android applications code (most likely in the C++ code you have that either is your application or helps your application talk to Reader Mobile SDK). One thing to know about these new extern functions, if you do not want to change how your application works and where it stores the data that Reader Mobile SDK writes, then all you need to do is have your implementation of these functions return an empty string and Reader Mobile SDK will continue to work as it always has for you and your application. However, if you are like us and want to make sure no one else is interferring with your applications data from Reader Mobile SDK then you will have to decide what the best route for implementing these methods is for your application. We like to leave the implementations for our customers as they know their applications better than we could ever hope to know them.

If you get stuck though, hopefully you have found this blog post where we are about to describe what our DL Reader for Android application does. If you haven’t found this blog then hopefully you have source code to DL Reader for Android so you can look at our implementation of these functions for help (if you haven’t found this blog though you can’t see this message, hmm! Hopefully you get help either way).

How we are going to be using these new hooks

Let’s dive into how DL Reader for Android makes use of these new hooks for storing its data.

The extern function getXMLFileStorage() is meant to be used as a way for Reader Mobile SDK to ask your application where it should write the various XML files that are relevant to the DRM system for your application. These files would be what Reader Mobile SDK refers to as activation.xml and device.xml It is important that these files be stored in an application specific location because each application may implement deactivation of a device differently (and you do not want your users to have their activations wiped out because they deactivated a different Reader Mobile SDK based ebook reading application).

Here is how we implemented these extern functions in DL Reader for Android.

In our C++ code for connecting Reader Mobile SDK to our Android code, we defined to functions dp::String getApplicationPrivateStorage() and dp::String getXMLFileStorage(). These functions just call the following methods that we have defined in our Android code.

<code>    private String getXMLFileStoragePath() {
        return XMLFileStoragePath;
    }

    private String getFulfilledBookPath() {
        return fulfilledBookPath;
    }
</code>

You will notice that these methods just return member variables of the class they are part of. In DL Reader for Android, we initialize these members when we initialize Reader Mobile SDK so that we have one place where all Reader Mobile SDK settings are configured. The values we pass when initializing Reader Mobile SDK come from

These both use the Context object from the application that is running, in our case DL Reader for Android.

How we think application developers can make use of these

We hope application developers who are writing applications for Android that are using Reader Mobile SDK will be able to use these new hooks in Reader Mobile SDK to help alleviate some of the problems that users of their application run into when working with the DRM system in Reader Mobile SDK.

One other nice thing about using the methods that Android provides for getting paths to store files is that when your application is uninstalled (why would your users ever uninstall your app?) the files that are written in these locations are automatically removed for you. This just means that users will not be able to complain that your application left their device cluttered with files that are now useless to them.

Caveat about activation limits within the Adobe DRM ecosystem

Earlier in this post, we hinted at some known problems with how applications handle storing their activation/device.xml files. These problems arise because Reader Mobile SDK is flexible (which is great, we want it to be!) it just means that we have to encourage best practices a little more than we have been.

The downside of using application specific storage for activation/device.xml is that for each Reader Mobile SDK based application a user has installed on their device, each time they activate an application on that device they are using an activation for their account. This means that if you sign up for a new Adobe ID and install then activate 6 different Reader Mobile SDK based applications, you have just used all of your activations for the year and cannot activate any other device with that Adobe ID.

Sometimes there is no perfect solution, you can only make things a little better!

Leave a Reply

Your email address will not be published. Required fields are marked *