Today, we are going to start with an important question : where do your Android applications store their data? Do you know off the top of your head? Do you use internal storage or external storage? Are you writing the data to a private location that only your application can read or are you writing to a public directory?
When we started working with Reader Mobile SDK and developing our DL Reader sample eBook application, we were new to the world of developing applications for Android and Android was still relatively young. For the past 4 years, we have stored data in DL Reader for Android in a few different places (depending on what kind of data it is). We have never gone back and thought through why the data was being stored where it is; it was just a given “this is where this type of data goes and this other location is where this other type of data goes.” We did not have good answers to some parts of our storage architecture and so we are reevaluating whether the decisions we made should stay or go!
In DL Reader for Android, we have been storing eBooks in a public location on the user’s SD Card in a folder named “Digital Editions.” This was because we went into this project with the thought that users would be plugging their Android devices into their computer in order to sync media between their computer and their mobile device. Fast forward a few years, users now have the ability to purchase content on their mobile devices and the number of services out there that will sync content wirelessly for you from a mobile device to your computer or any other mobile device, there is less need to have a highly visible and recognizable name for the directory where a user’s eBooks are stored. If you take it a step further and compare Android to iOS, iOS does not give users access to the entire filesystem, only parts of the filesystem that each specific application is allowed to access. (There are some thirdparty tools out there that give users more access but those are out of scope for this discussion).
So what are we doing differently now? We have started by providing a hook in Reader Mobile SDK for Android that allows application developers where to store their applications eBooks instead of it being a compile time option for Reader Mobile SDK. Then we expanded our scope and looked at other data that Reader Mobile SDK writes and provided a hook to allow application developers the same control over where information required for activation is written. While these changes may seem small and easy to make, they are bits that we don’t think customers of ours should have to write on their own and then worry about ensuring that all of the functionality within Reader Mobile SDK that relies on activation data or eBook content still work.
The other goal that we hope to accomplish with these changes is to eliminate some of the confusion around the DRM system that end users of Reader Mobile SDK applications tend to run into. The hooks that we have added to Reader Mobile SDK are designed to be used by application developers so that their applications data can be written to storage space that is designated for their application. By making these hooks readily available in Reader Mobile SDK we hope application developers will take advantage of them instead of letting Reader Mobile SDK write all of the data to shared folders on Android where other applications that use Reader Mobile SDK may overwrite your applications data.
DL Reader for Android will start making use of these new hooks in its next release and we highly encourage our Reader Mobile SDK customers who are building applications for Android to think about where they are storing their applications data. Think not only just about where you are storing your data but how it is impacted by other Reader Mobile SDK applications, if you haven’t tested your application installed on a device with other Reader Mobile SDK based applications you should! Don’t be a bad neighbor!
Stay tuned for the follow up post for this discussion where we will dive into some of the technical details and look at some code!