Access PDF files from 'res/raw' or assets folder programmatically to parse with given methods

Explanation:

Right now this program accesses a file from a file manager that takes the selected files path and sets it to the 'mFilename' EditText field. The show PDF button listener below shows the String 'pdffilename' gets assigned the String contained in the 'mFilename' EditText field. The PdfViewerActivity is started and the String 'pdffilename' is passed as an Extra. In the onCreate() the intent is checked if null or not. This is where I think the change can/should be made. The String 'pdffilename' is assigned what you see below. What I want to do is store the PDF files in one of two ways... int the 'res/raw/example_folder/example.pdf' or in the assets folder. I want to assign 'pdffilename' programmatically with the path for where I am storing these PDF files. I have tried many different approaches all of which have either did not compile, caused errors, or caused a "file: res/raw/example_folder/example.pdf does not exist!".

So Basically...


I want to store PDF files in 'res/raw/folder_example/example.pdf' or the assets folder
I want to access these files from the code as in I do not need to use a file manager
Anyway that will solve this would be the biggest help, I am pretty good with Java, but I am by no means a superstar so please explain a little with your code


Thank you so much and I will be standing by to answer comments and edit this post. I hope this post will be helpful to other users so I will be posting the code for the solution. when completed. Thank you again!

Show PDF button Listener in PdfFileSelectActivity...

OnClickListener ShowPdfListener = new OnClickListener()
{
    public void onClick(View v)
    {
        mFilename = (EditText) findViewById(R.id.filename);
        String pdffilename = mFilename.getText().toString();
        Intent intent = new Intent(PdfFileSelectActivity.this,
        PdfViewerActivity.class)
        .putExtra(EXTRA_PDFFILENAME, pdffilename);
        startActivity(intent);
    }
};


PdfViewerActivity's onCreate() invoked from show PDF Listener above...

Intent intent = getIntent();

if (intent != null)
{
    if ("android.intent.action.VIEW".equals(intent.getAction()))
    {
        pdffilename = storeUriContentToFile(intent.getData());
    }
    else {
        pdffilename = getIntent().getStringExtra(PdfFileSelectActivity.EXTRA_PDFFILENAME);
    }
}

if (pdffilename == null)
    pdffilename = "no file selected";

setContent(null);


setContent() called from above (if needed) ...

private void setContent(String password)
{
    try {
        parsePDF(pdffilename, password);
    }
    catch (PDFAuthenticationFailureException e)
    {
        System.out.println("Password needed");
    }
}


parsePDF() called from above (if needed) ...

    private void parsePDF(String filename, String password) throws PDFAuthenticationFailureException
    {
        long startTime = System.currentTimeMillis();
        try {
            File f = new File(filename);
            long len = f.length();
            if (len == 0) {
                mGraphView.showText("file '" + filename + "' not found");
            }
            else {
                mGraphView.showText("file '" + filename + "' has " + len + " bytes");
                openFile(f, password);
            }
        }
        catch (PDFAuthenticationFailureException e)
        {
            throw e;
        } catch (Throwable e) {
            e.printStackTrace();
            mGraphView.showText("Exception: "+e.getMessage());
        }
        long stopTime = System.currentTimeMillis();
        mGraphView.fileMillis = stopTime-startTime;

   }


Thank you again!


Question: Address Windowing Extensions Overhead
Answer: 
  Has anyone done an research as to the overhead created by enabling AWE on the 64-bit OS/SQL combination?


This is one of the Myths that Paul Randal clearly debunks in his famous series - A SQL Server DBA myth a day


  On 64-bit systems (2005+): AWE is not required (and in fact enabling it does nothing).


Also refer to Fun with Locked Pages, AWE, Task Manager, and the Working Set… by Bob Ward :


  The AWE APIs for 32bit and 64bit SQL Server systems are used for different purposes. In 32bit it is really to extend memory access beyond 4Gb or to enable the AWE feature. For 64bit systems, it is to possibly gain performance and to “lock pages” for the buffer pool.


and 


  In fact, the code for SQL Server for 64bit systems ignores awe enabled sp_configure option. It is a “no-op” for 64bit SQL Server systems.