In this tutorial we’ll step through the process of using the Android’s builtin support for SqlLite to store a password and retrive it in a rather interesting attempt at creating a guest dialer application. When I first imagined a guest dialer I had in mind an application that would allow you to let someone use your phone without giving them total access to your incomming messages and other sensitive data. However, a lock-in application basically classifies as a malware when you think about it so whatever… at least I learned about the SqlLite API.
Before begining this tutorial make sure you have the following…
- Java runtime and SDK installed
- Android SDK
- Some IDE which supports Android development such as Eclipse or IntelliJ IDEA(the free community edition can be used for Android Dev)
- Some familiarity at least(not much don’t worry) with Android Development
Within your IDE of choice create a new Android project and call it Secure Dialer(actually you can name it whatever but I’ll just refer to it as Secure Dialer throughout this tutorial).
Now locate the pre configured file called “AndroidManifest.xml”.
The AndroidManifest file is the standard configuration file for Android applications.
Its where you determine which permissions you demand from the phone OS as well as where you setup the various activity screens and many other things.
Just think of the AndroidManifest as the app’s system profile if that helps.
To start us off lets declare the permissions we need the end user to accept in order for our application to function correctly.
|
|
Next we’ll fill out the
the activities and setup any intent-filters which we might need as well.
|
|
Now go ahead and save the new AndroidManifest.xml with our changes in place.
Next up is the resource file strings.xml.
strings.xml if you need a refresher is a special resource file that is standard across Androidapps because its the file where you define all of the text strings which will appear throughout your app.
Although is practical to define strings within the .java files its considered good Android development practice to keep as many of the applications strings within the strings.xml.
You might think its crazy but for large applications it makes updating text notfications a piece of cake.
So navigate within your IDE to res/values/strings.xml or create the file if it doesn’t exist.
Remember all of those @string/some_name values within the AndroidManifest.xml?
Well that is how we reference the values stored within res/strings.xml.
Moving along next create the Java class file HomeScreen within your applications src folder if you want to follow along with the code I have it under
Don’t worry about all of those string values you just typed or pasted we’ll use them shortly as we introduce each activity screen.
As is normal with Android development we will first create the visual layouts and then once all our buttons and views are setup we then add Java to support the various actions we want to allow our users to make.
Be warned though that this style of visuals first and then application logic might sound strange if you’re comming from a web development MVC or MVVM background in which you first design your Models before hooking up controller logic before finnally designing a UI; but don’t let it get to you too much because you’ll see how its much easier for you to structure your Java code since you basically build application logic on top of objects created from your visual layout.
But enough chit chat, create a new file “homescreen.xml” within
|
|
The homescreen is fairly basic it will just appear as three buttons vertically tiled.
When we get to the code for the homescreen you’ll see how easily you hookup code to support the android:onClick= tags from your xml file.
Now create the Java class file “HomeScreen.java” within your project’s src/ folder.
Here you’ll also notice a class called “PasswordDB” created, that is the object representation of our SQLite database which is the focus of the article and we’ll cover it in depth later on.
|
|
Pay attention to the homescreen_button_click_handler.
Remember inside our Homescreen.xml file where we defined the onClick attribute for each of the three buttons?
Now you see how easy it is within the Java code to look up the button’s unique id name and write handler code, it just becomes a switch case on the getId() method of the View which generated the click event.
To think if you tried it the other way around you would have foolishly built up three different button handler events where we have just a single button_handler for the entire Homescreen.
This style of design also makes our code very modular; if you wanted to add another button its as easy as popping in another case statement.
Looking at the button_click_handler code when the user presses the homescreen_dialer_button we launch the Dialer activity screen… lets do that.
As before we’ll create the dialer layout first, so create the file “dialer.xml” within the layout directory res/layout.
|
|
As you can guess all of the numerical button are what you should expect from a phone dialer.
Of intrest is the non-focusable editbox where the phonenumber will be displayed as the user types and the three buttons near the bottom; dial, clear and done.
The layout as you can see is rather plain but the interesting bits will come next when we add the Java code.
However before that we need to creat the layout for the password prompt which will display once the guest has finished making a call and might potentially have the chance to muck around with your phone.
Add the file “dialerpassword.xml” to the res/layout folder.
|
|
Finally create the Java class file “Dialer.java” and place it within your src/ folder.
Stepping through the code for the Dialer class you’ll notice that its relatively simple.
Since the activity is once again button based the meat of the code involves deciding what we should do once each button handler event is triggered.
A quick thing to notice is that the Dialer class we defined extends the HomeScreen where we intialized the password database object; so all of the password interaction is due to our great use of inheritance.
Anyhow the basic idea for the Dialer activity is the following…
- Pressing the numeric keys lets the user enter a phonenumber
- The clear button should delete a numeric character one at a time
- Dial… makes a phonecall
- Done should prompt the user for a password, if correct unlocks the app
What you’ll notice here is that the prompting for a password is how we make the dialer somewhat secure. If the wrong one is entered the user should theorectically have no other access to your phone meaning they can’t touch your apps, peek at your emails or do anything else.
Looking at the code you’ll see the function make_password_dialog() which creates the kinda mini embedded activity when the user triggers the dialer_done_button click event.
The remaining code within the Dialer class involves the TelephonyManager which is the Android API’s way of letting developers controller the actions of the phone listener and receiver.
Its rather easy to understand after you force yourself to think of the Phone as advancing across as series of states such as IDLE, OFFHOOK, LISTEN_CALL and create a mental map of those states as you normally talk on the phone. Now we’ll return back to the Homescreen and add in the code to support the new and reset password buttons.
Each of the buttons will have a layout and Java class file associated. Lets begin with the NewPassword class, create the file “newpassword.xml” within the res/layout folder of your Android project. The xml rather easy to understand as its just a regular enter password and repeat it once type of layout you’ve seen all over the place.
|
|
The Java code should be titled “NewPassword.java” and stored within the src/ folder of your project.
The code consist of letting the user enter a password into the editText box, and validate that the repeated value matches the original.
Once the validation has been accepted we make a DB transaction and store the password.
If you pay enough attention to the newpassword xml and Java code behind you’ll have no trouble at all with the resetpassword code as its very similar.
We’ll begin with the layout for the resetpassword code, so create the file “resetpassword.xml” within the res/layout/ folder of your project.
The addition here for the reset password xml layout is the entry for the current or old password. We going to assert that the value entered there must be found within the database before we can create a new transaction to store the value of a new password. Now create the file within the src/ folder of your project called “ResetPassword.java”. I was extra careful to write useful comments within this file so be sure to read them before moving on to the last part.
We are now ready to explore the basics of the Android SQLite API.
Within the src folder of your project add the file “PasswordDB.java”.
The static strings we declared above represent the name of our database, table and two columns.
The password number or PassNo will be the primary key and the string value
of the password(this is not a mission critical app so we’re not going to encrpyt it) will be its stored value.
Next we’ll write the constructor for the database which will create the databasewith the name we gave it within the string db_name.
With our database in place the next step is to create the Table.
The code below will accomplish just that, look at the JavaDoc I wrote to see the corresponding SQL.
The next method onUpgrade() is a required function but we’re not going to actually implement it since we don’t need it for this example.
We’ll of course need a way to insert a new password into our database.
The method set_password does just that. All its doing is calling a basic SQL insert into query but using the Android API helper method insert();
Much like a Java property we need a getter to accompany the setter.
However here we’ll first write a raw query which will place a cursor at the first result row that was found from our SELECT statement.
Database cursors can be though of as table iterators.
The cursor will begin at the result table itself, you must first move it to the result row to begin reading data.
Once at a result row you have to move the cursor column by column and read the rrow value from each.
Since we are only going to be storing a single password the first row result will always contain the password we want to fetch.
Now the question becomes how do we update an existing password?
To do so we have to use the update() method which is another Android SQLite API wrapper around the traditional SQL UPDATE WHERE statement.
Looking at the JavaDoc I wrote you can see how we would write this if it were a regular SQL statement.
Despite the Android SQL API being a little verbose(this might change in the future) the parameterized input means that we would be safe from any type of injection attacks since we’re not passing a rawQuery from the user input.
In short using the parameterized wrapper methods is more code but it saves you from the potential danger of calling rawQueries which substitute in user values.
Lastly we need a way to verify if a password has been set or not.
This will allow us to determine when we need to prompt the user for a reset.
Its short and sweet, just run a select query and count the results.
Perhaps you got lost(its better if you followed along closely) but here is the PasswordDB class in full.
So there you go, an Android application that makes use of the SQLite API. Perhaps you can extend this application or something.
Anyways… enjoy your guestDialer app.