Android Studio vs Eclipse

When it come to Android app development there are really two choices Android Studio and Eclipse. I have been using Eclipse for Java and Android development the last 4 years. Besides the Android emulator disastrous function which makes using emulators a torture, I really have good impressions about working with Eclipse; you could say I am a fan. Nowadays Eclipse lacks official support from Google but it is easy to install Android IDE through the Eclipse marketplace and have your system up to date. In marketplace you may find a huge collection of libraries and development tools that may boost you productivity and potentials.
But then Android Studio arrived. It is really not that new as it is based on IntelliJ platform that has been around for some years. The thing about it is that it is the official Android IDE supported by Google. So you must give it a try.
In comparison to Eclipse, Android Studio has some valuable advantages like better emulator performance, more comprehensive error messages and reports. It also loads almost automatically the required libraries and references and downloads the necessary Android SDK components.
The downside of using Android Studio is its demand in computational and storage resources, at least when used in MS-Windows. Even when performing simple tasks it requires really large amounts of RAM. You can sense your whole system slowing down even in modern computers. Compiling and packaging the same application with Studio and Eclipse is a completely different story and it takes a while or a lot more in Studio, while both produce basically the same product.
In storage requirements things are worse. Apart from its installation files Studio stores strangely large amounts of data in other places. In the AppData folder it stores some gigabytes of data, for some reason . While in operation it creates a few gigabytes of temporary files. In the users folders, Studio also stores some gigabytes of probably personalized data. It really makes you wonder if all these are really necessary, other IDE’s do not ask for so much and certainly Eclipse is one of them. Another thing I noticed is that for the same applications, the project files generated by Studio are even ten times larger in storage space then those generated by Eclipse. Still they produce the same applications.
My opinion based on all these, is that if you don’t need an emulator then Eclipse is a more productive tool for application development.

Maps are better displayed on big (TV) screens

TV sets these days have become more powerful than ever. They are equipped with powerful operating systems like Android and WebOS and their screens seem more magnificent than they could ever be. So why not to use them for map display?
Maps contain information related to spatial data and it is always better to view them with a big clear view of the spatial information they carry. For instance, sometimes it is not so informative to view a generalized weather map in the small screen of a smartphone; a big screen or printing the map in a big paper give you a clear insight of the situation it represents. Also a school could use a set of digital maps for educational purpose rather than using a few printed maps not viewable from distance.
Of course professionals know these things and the use big computer screens for drawing maps but most other people use small screens even at home. Personally, I always thought that TV screens could have much more potentials beyond their traditional use. On this spirit I have released two applications that link viewing my web mapping application WMS Map Viewer On Line to Android TV and Amazon TV. The result is really great try it.

Play Store link

Amazon Appstore link

Change layout dynamically in Android applications. A case study.

Android applications are usually built to function in a variety of devices that have different screen dimensions and also they must be functional in any orientation of the screen and in any change of the orientation. Moreover the efficient use of space especially in devices with small screens is very important and gives great value to the application, so the GUI of an activity must be designed with special care to screen sizes and orientation changes.
The indicative way to design the GUI of an activity is to prepare a layout file for it. This is a more straight forward procedure than defining the graphical elements of your app programmatically and is easier to handle and test. All the default layout files are stored in /res/layout directory of the projects file structure. In case you want to prepare a layout file for an activity with landscape orientation, you have to create directory /res/layout-land and you place the layout file in there. When the size of the screen matters and you want different UI for different screen sizes then you must create a layout for each case. For instance, a layout designed for screens with smaller size larger than 600 dp must be placed in a directory named layout-sw600dp and if you want to combine screen sizes and orientation you must place the appropriate layout file in the directory named layout-600dp-land.
All the layouts that refer to the same activity must have the same name regardless of the directory they are stored. When an app is executed, Android will search for the most appropriate layout considering the screen size and orientation. In case there is not a special layout defined, Android will use the layout stored in the default directory.
Problems start when some of the elements of the screen change dynamically while the app is running and a layout has already been loaded. In most cases the change in the orientation of the screen causes troubles in the dynamically changed elements. When orientation changes, Android usually reloads the activity losing all the changes the user has caused. In order to avoid that you must edit the manifest file and in the activities that are declare some how like this

        <activity
            android:name=".app.MyActivity"
            android:label="@string/title_activity_myactivity" >
        </activity>

add one line of code changing them like this

        <activity
            android:name=".app.MyActivity"
            android:configChanges="keyboardHidden|screenSize|orientation"
            android:label="@string/title_activity_myactivity" >
        </activity>

This tells Android that you know what to do with your activity so it shouldn’t change anything on its own. Let’s see now what you should do when it is you that you want to cause layout changes when orientation changes. In order to present this more efficiently I will use the example of my app called Map This Way.
In an activity of this app called activity_line the user may record the GPS tracks along a route. In the layout there is some text that is updated with the current GPS coordinates and a map view that shows user’s current location. In big screens when the screen is in landscape orientation the map is better to be on the right of the screen and the text on the left and when the screen orientation is vertical the map view is better displayed under the text. In small screens the map view should always be under the text. In order to do this I prepared layout files for all cases. Then I had to arrange how the app will behave in screen orientation changes.

Orientation changes are detected and manipulated by the onConfigurationChanged method which must be overridden.

@Override
public void onConfigurationChanged(Configuration newConfig){
     super.onConfigurationChanged(newConfig);
     setContentView(R.layout.activity_line);
}

The above code reloads the UI of the activity using the most appropriate layout file for the new orientation of the screen. The advantage of using this technique instead of letting Android do the changes is that in this method you may add code to define how the activity elements will be displayed in the new screen. The disadvantage is that the elements are initialized and reloaded so you will have to add code so as to initialize them properly and update the values of the layout elements with the changes that have occurred so far. Also you have to restart procedures that may have stopped after orientation changed like advertisement display etc.
In the case of my app the map view has to be updated so the users will see their current location and if the mapping procedure has started the colors and functionality of layout elements has to be adjusted accordingly.
In general, a good way to deal with such situations is to initialize the layout elements in the onConfigurationChanged method as you did in the onCreate method. So for update of the map view of my app I use the method showmap(x, y) which updates the location of the map and it is executed in both methods.
Another problem occurs when you have to pass some value from a variable that affects layout elements to the newly initialized elements after orientation changes. For this, the use of some global variable is very helpful. In my app when the mapping procedure has started, a red button appears which may be pressed by the user and cause the stopping of the mapping procedure. The way I worked around this issue is the declaration of a global boolean variable called mapping which takes the value true when mapping has started and false otherwise also the declaration of a global Button instance. Then I used both in onConfigurationChanged method.
All the above were formed as follows.

@Override
public void onConfigurationChanged(Configuration newConfig){
    super.onConfigurationChanged(newConfig);
    setContentView(R.layout.activity_line);
   showmap(x, y);
   if (mapping){
        button1=(Button) findViewById(R.id.button1);
        button1.setBackgroundColor(0xffff0000);
   }
}

Then activity_line is functional and ready to use.

Building interaction between Android and Javascript

In this post I present methods on how to build interaction between Javascript content in a webpage and the Java code of an Android application. When building an application with web content (build-in or loaded from network) there is always the issue on how it will communicate with the rest of the application. The interaction has to be two-way. The web content probably hosted in a webview has to be able to affect the rest of the application based on user interaction and Android must be able to change the web content. There is not a unified way to build a two-way bridge between the two interfaces, Javascript and Android have to bind with each other using separate processes.
Let’s suppose that you are building an app with one activity named Activity1that hosts a webview which opens the local file HTML1.html (the examples that follow also work when files are somewhere in a network and not local). In Activity1 there are some String variables v1, v2, v3. Corresponding variables with capital letter names are defined in some javascript code enclosed in HTML1.

At first the variables and the webview in Activity1 have to be declared properly and Javascript support has to be enabled.

Code to place in Activity1

String v1, v2, v3;
WebView webView;

//In the onCreate method add
webView = (WebView) findViewById(R.id.webview);
WebSettings webSettings = webView.getSettings();
webSettings.setJavaScriptEnabled(true);

Variable declaration in a script in HTML1.html

var V1=”Value of v1”;
var V2=”Value of v2”;
var V3=”Value of v3”;

Updating variables in Javascript

I present two techniques for updating the variables in Javascript. In the first the necessary code will be loaded in Javascript before HTML1 will be loaded in webview and this is the main advantage of this technique.
In order to change the Javascript code that runs in webview, I create programmatically a file that contains the code I care to run and then I insert it to HTML1. As a technique may not be so elegant, but it has certain advantages. Another advantage of this technique is that the preservation of the information that regards the variables does not depend on the life circle of Activity1. So, the file may be store while running Activity1 and other activities that will open in the future may read it and update their variables.

In Activity1

At first the path of the file that will be dynamically created has to be defined. A good choice is to place it in the files directory of the application. The directory path can be accessed using the getFilesDir() method. Then it is only necessary to add the code that creates the file.

File jsfile = new File(getFilesDir() + File.separator+"new.js");

public void filecreator(){

v1="new value1";
v2="new value1";
v3="new value1";

BufferedWriter buffer = null;       
    try{               
        buffer=new BufferedWriter(new FileWriter(jsfile));
        buffer.write("V1="+v1+";");
        buffer.newLine();
        buffer.write("V2="+v2+";");
        buffer.newLine();
        buffer.write("V3="+v3+";");
        buffer.newLine();
        buffer.flush();       
        buffer.close();
}
    catch (IOException ex){
        String ioerror=ex.toString();
    }
}

Then simply call the method while running Activity1.

In HTML1.html

Insert the newly created file in the body or the head of the html code.

<script src="jsfile.js" type="text/javascript"></script>

If both HTML1.html and jsfile.js are in the same directory then it is not necessary to determine the full path of the file and the code above is enough.

Another more elegant technique is to load the script using method
webView.loadUrl(("javascript: /*some code*/")
In this case you only add the following code in Activity1 and don’t make any changes in HTML1.

webView01.loadUrl("javascript: V1=’new value1’; V2=’new value1’; V3=’new value1’");

The above script will be executed after HTML1 has been fully loaded in webview. You have to be careful on this, as executing the script before loading the html file might lead to undesired behavior.

Updating Android variables from Javascript

Let’s see how running Javascript can affect the variables of Activity1 by modifying the example in Android Developers site (link).

In Activity1 

Add a WebAppInterface class. The methods of the class must overidde JavascriptInterface in order to work with the latest versions of Android.

public class WebAppInterface {
   Context mContext;

   WebAppInterface(Context c) {
       mContext = c;
   }
       
   @JavascriptInterface
   public void updatevariables(String V1, String V2, String V3) {
        v1=V1;

        v2=V2;
        v3=V3;
   }

}

In this implementation, the method updatevariables is called from Javascript that runs in the webview. The values that should be set in the variables v1, v2 , v3 are passed to the formal parameters of the method (String V1, String V2, String V3) and the code that follows updates the variables in Activity1.

Code to place in HTML1.html

function updatevariables (V1, V2, V3) {
    Android. updatevariables (V1, V2, V3);
}

In some part of the script in HTML1.html call the function updatevariables and the values of v1, v2, v3 will be updated.

The illegal and misleading practices of mobogenie.com

Lately I found out that that there is site called mobogenie.com in which two of my Android apps are published. I have not submitted them to this site and I don’t really want them published there. But this didn’t stop them from presenting the apps in the site and putting a download button.
When you press the download button you get an .apk file that it is supposed to be the app that you are seeing in the site it has the same name. In reality it is the “mobogenie” app that tricks you to install it in your device. Then, perhaps you will have the chance do get the app that you actually want. In their disclaimer they admit that they have no control over the app submissions, they don’t really know if the app that you submit is really yours. A few days ago there was a link in the main page with directions on how to claim your own app from mobogenie if you find it there without having submitted it yourself.
Of course I send an e-mail, they respond that they will look at it, two weeks later no answer.
It turns out that they have built a whole market in which is not clear if they have the right to distribute the apps that they distribute. This practice is illegal, at least in my case it is clear in the EULA of my apps that they may be distributed only be authorized distributors; mobogenie is not one of them.
It is also misleading. The app that they let first to download is not the one you asked for.
Most of the app stores and markets have an app that they ask you to install before start downloading apps. But it is quite clear when you download the app of the appstore and when you download the app that you want. Before submitting an app to legitimate appstores like Amazon and Google Play you go through an extensive check of your ID, they even cross-check the information you provide with IRS. In mobogenie they could do something like this, but they don’t seem to care as their location is in Asia and you will probably won’t bother to form an international law complaint.
Besides, my apps that I saw in mobogenie are distributed from Amazon and Play for free, the mobogenies probably think that I should not mind having in their site my free apps. They could ask first.

Open a file with default application in Android

Here is a technique to program an Android application to open files using the default application that it is associated with them. A part of this technique can be found in many other sites on the internet. The advantage of this technique is that you don’t need to specify the type of the files or the application that is associated with them.
At first you create a method and you input in it a file object pointing to the  desired file (let’s call it testfile), then it is only necessary to create an intent setting setAction(android.content.Intent.ACTION_VIEW) and intentview.setData(Uri.fromFile(testfile)) and then start an activity with this intent. When this method is executed the application associated with the testfile is executed and it opens testfile without closing your application.
The only problem with this technique is that there might be the case where there is no application associated with testfile. This can happen when there is no suitable application or the testfile has no extension. In this case there is an exception “android.content.ActivityNotFoundException” that must be handled. A convenient technique is to enclose the code in a try-catch structure so as to catch the exception and execute some other code that will direct the program to do something else, like opening the file in a text viewer or display some message.
Here is the code

File testfile = new File(//path of testfile);

 public void openfile(File testfile){
        try{
        Intent intent1=new Intent();
        intent1.setAction(android.content.Intent.ACTION_VIEW);
        intent1.setData(Uri.fromFile(testfile));
        startActivity(intent1);
        }
        catch(android.content.ActivityNotFoundException exception){

            //Do something else
+
        }
}

If Android was like an ordinary Linux distribution.

When Android was initially developed, it was design to work in devices with little processing capabilities; not much memory, slow processors, very low power consumption. So, the developing team of android took Linux, removed all the not so necessary features and Android became light and not very demanding; more like an embedded system.
Nowadays, Android enabled devices are equipped with a lot of memory big screens and multicore processors which make them powerful enough to carry complicated and demanding tasks. Still, the philosophy and architecture of android hasn’t changed much. Although I like Android very much, I can’t stop wondering how would it be if android was like an ordinary Linux distribution?

If Android could handle multiple user accounts like Linux 

 

While Linux is a real multiuser system, Android is mainly designed to handle Google accounts rather multiple user accounts. If Android was a multiuser OS like Linux each user would have his own desktop, home directory and settings. Each user would be able to do anything in his home directory like running a script or change permissions in a file, while the rest of the system would be protected. Currently, if you want to do these things you have to Root your device exposing the whole system. Also, each user could have installed his own private applications. To put it in a simple way, when children are coming to my house I could just log in to my tablet as a guest user and give it to them to play without worrying that they will mess up my e-mail application.

Android could have a fully featured console

There are many terminal emulators you may install in android. But if you do so, you find out that most of Unix commands do not work as they are either not installed or they require administrator user rights. As there is no home directory for you this situation affects the whole system; there is no directory in which you can do whatever you want. If you are an advanced user and you want to carry out more advanced procedures you have to install Busy Box a collection of Unix applications compiled for Android but you still need administrators rights; administrator accounts are not accessible. So you buy a high-tech device and you have to hack it so as to get the most of it. How sensible can this be?

Network transparency and remote system administration

With Linux things are simple. Using the console of your computer you can log in to some distant system and operate it like if it is right next to you. This feature is quite useful when you want to administrate some distant system without physical access to its hardware.  This is a very advance feature of Unix. You don’t just get the control of the desktop of the distant system, as it happens with most distant administration applications of Windows. In Unix you actually log in to the system itself.
If such a feature was easily accessible in Android, then we could talk about the support of distant system administration on the move. You could be in an island in the middle of the ocean and check the network traffic of you server in New York. Currently, if you care to do this it is necessary to install an application in your server and a corresponding one in your tablet and then set up a connection and you will probably end up being in control only of the desktop of your server ...... boring.
It is my belief that Android should gradually adopt the traditional features of Linux that are now hidden or ignored. Such an approach would benefit advanced users a lot.

Android application submission; Amazon App Store vs Google Play.

I recently submitted applications both in Amazon App Store and Google Play and I think it is interesting to discuss the main differences of these two services. As far as it concerns android applications both of them want to work as electronic stores, so one might think that they should have similar functionality. The truth is that they have different approaches on the way they treat developers and on the demands they have from them. Let’s look at their differences in sections.

Registration

In Amazon you need to perform a full registration right from the beginning. The information you provide are cross-validated with IRS and your registration looks and actually is very formal. It is also for free. In case you submit applications for which you expect to get some royalties you only have to add a bank account.
In Google Play you have to create a Google account, then pay 25$ using a valid credit card; prepaid cards work fine, I tried a debit card and it didn’t work. If the apps you submit are for free your registration information are not cross-validated and I think there is a relaxation in the control of the accuracy of the information you enter. The only cross-validated information you have entered up to this stage is your credit card. In case you expect to make money from you apps you need to get registered as a trader. At this point your registration is cross-validated and you need to be accurate in what you declare. Also you need a bank account.

Target devices and promotion

Google Play wants to please everybody. So while submitting an app, you are welcomed to provide screenshots and graphics suitable for all kinds of devices; small phones; larger phones or tablets; 10’ tablets. At least 3 screenshots are required. You are welcomed to put a YouTube video but you need to apply promotional images of different resolutions for users that will not watch your video. Besides any low resolution image, you are also required to apply a 512 x 512 pixel icon of your app.
After acceptance of your app you may promote it any way you wish. You can pay for advertisements or do your own promotional campaign.
Amazon produces its own Android devices. So, you are highly motivated to submit apps compatible with them and also use their SDK. Amazon devices are the Kindle devices (readers, fire etc) and the new Fire Phone and Fire TV. Also, you are motivated to support the latest high-end devices with HD screens etc. Your app may be accepted even if you do not fully support these devices, but this is not a wise thing to do. Until February 15th 2015 an app that supported Kindle and HD was promoted through Amazon advertisement system getting as bonus many thousands of appearances in devices of potential clients. This promotional benefit was called Developers Select program; unfortunately it has stopped. This required that you will also provide screenshots of 1200 x 800 pixels or higher. Extra promotional motivations was given for support of special features of Fire Phone and Fire TV.
For most Kindle devices your apps needs to maintain compatibility with some older Android versions and have support for HD screens. For Fire Phone you need to integrate special widgets designed for the phone using its SDK. For Fire TV the support of its special controls is required.
Another difference between the two services is that in Amazon you can set a period during which your app will be available with a discount, even for free and after this period it will return to its normal price. In Google this not possible, you have to manually modify the pricing of your app and once you select to give it away for free this cannot be changed in the future.

Submission procedure

Amazon does not support Google Maps later than version 1.2 at least up to now.
In Amazon you can test your application before submitting it and even distribute it to some reviewers to get some feedback and pre-submission reviews. As it is announced 75% of the submitted applications pass the tests.
Google Play does not allow the packages in your app to have a prefix name “com.example” although this is a default choice in Eclipse. This is something you find out a few seconds after you submit your app; no one warns you earlier. In Google you make a full submission and then your app is tested.
Another issue with Google is that it requires the title of your app to be at most 30 characters long. This does not happen with Amazon. So, if you publish in Amazon an app with a title longer than 30 characters and then you want to publish it in Google Play you will have to shorten its title.

In-app purchase

A key difference between the two services is that when you purchase an in-app item in Amazon your purchase is not time restricted, while Google Play allows the developer to sell in-app items and services for limited period of time, such as annual subscriptions for something etc.

In-app advertising

For the advertisements of Google that you display in you app, you will be paid according to the number of times that the users have clicked on them. The same thing holds for advertisers, they get charged for the number of clicks on their advertisements.
In Amazon things are quite the opposite. Advertisers pay and developers are getting paid for the number of “impressions” of each advertisement. One “impression” stands for a single appearance of an advertisement in a device of some user through an app. Unfortunately Amazon ad network currently covers  only U.S.A., U.K., Germany, France, Spain and Italy.
Comparing the two pricing policies I have to say that a click of a Google app costs more than an impression in Amazon; but this is not a good criterion. Which policy is more profitable is case-dependent. If your app is used quite frequently by your users, then the policy of Amazon sounds better; you may get more impressions than clicks. In case your app is used once a week of some short operation then the policy of Google may be more promising as you will not get many impressions.

Licensing - Protection from unauthorized copy

Both services provide mechanisms for protection of unauthorized copying of your app. And in both services the use of these mechanisms is optional. It seems to me than when you release a free app you probably don’t care about unauthorized copying but this is your choice.
In Amazon during the submission you may choose to use the DRM (Digital Rights Management) of Amazon. In this case Amazon puts its own signature in the apk file of your app. When a user installs an apk signed with DRM, the application of Amazon checks if the specific apk is authorized to be installed in the particular device. If so, the apk is installed and work without any further check or disturbance. If the apk has been illegally purchased the app is not installed.
In Google the licensing service is quite different. As a developer you have to add extra code in your application so it may use Google Play Licensing which is a network-based service. Google Play Licensing determines during the installation of an app if a given user is licensed to use the app. The code that the developer has to add in the app is the License Verification Library (LVL) provided by Google.
There is one thing for sure. If you choose to submit an app in both services and you want to prevent unauthorised copying of your app you may not submit the same apk in both services and the apk’s will end up having different signatures.

I can’t say that I prefer one of the two app stores more than the other. Using both of them is more interesting as a user and more promising as a developer.

Use dynamically placed editable elements in Android Table Layout

It may be very useful if in an activity of an Android application, the user is allowed to define dynamically the number of elements in a Table Layout. These elements maybe editable like Check Boxes, Edit Text fields or Spinners. After the user interacts with these elements the data are passed to the next activity generating some results.
Here is an example of an application in the first activity of which the user is allowed to define the number of CheckBoxes that will appear in a Table Layouts in the next activity. Then, the user may check some boxes and this will affect the text appearing in the final activity. The text in the final activity is a binary string where 1 stands for a checked corresponding CheckBox and 0 for an unchecked one.
I must give credit to the useful ideas found in the answers of a post of stackoverflow; find it is here.

In the main activity it is enough to place an EditText field in which the user will enter the desired number of CheckBoxes and a button that will activate an intent like the following which will send the number to the next activity.

        EditText editText1 = (EditText) findViewById(R.id.editText1);
        fnum=Integer.parseInt(editText1.getText().toString());
        Intent intent1 = new Intent(MainActivity.this, TableActivity.class);
        intent1.putExtra(DATA, fnum);
        startActivity(intent1);

In the next activity I form a layout with a scrollable Table Layout

     <ScrollView
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:layout_below="@+id/TextView02"
        android:layout_above="@+id/button1" >

    <TableLayout
        android:id="@+id/table1"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:layout_below="@+id/TextView02"
        android:layout_marginTop="30dp"
        android:layout_above="@+id/button1" >
    </TableLayout>
    </ScrollView>

Then in the Table Layout, there is a number of Check Boxes dynamically placed using a loop to add it in a Table Row.

       public class TableActivity extends Activity {
       public final static String LIST = "com.TableActivity.LIST";
       int fnum;
      TableLayout table;
      int[] data;
  
    @Override
       protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_table);
      
        Intent intent1 = getIntent();
        fnum=intent1.getIntExtra(MainActivity.DATA, 0);
        table = new TableLayout(this);
        for (int i = 0; i < fnum; i++) {
            TableRow row = new TableRow(this);
            CheckBox checkbox = new CheckBox(this);
            checkbox.setText("Box #"+Integer.toString(i+1));                   
            row.addView(checkbox);
            table.addView(row);
          }

        TableLayout tablelayout = (TableLayout) findViewById(R.id.table1);
        tablelayout.addView(table);
        }

Also I use a method in order to pass in the next activity the information of whether each Check Box is checked or not.

           public void done(View view){
            data=new int[fnum];
            TableLayout tablelayout1 = (TableLayout) table;
           
            for(int i=0;i<fnum;i++){
                TableRow tablerow = (TableRow) tablelayout1.getChildAt(i);
                CheckBox checkbox = (CheckBox) tablerow.getChildAt(0);
                if(checkbox.isChecked()){
                    data[i] = 1;
            }
            else{
                data[i]=0;
            }       
          }

It is easy to show the result in the last activity.

        Intent intent1 = getIntent();
        data=intent1.getIntArrayExtra(TableActivity.LIST);
        String s=Arrays.toString(data);
        TextView textView = (TextView) findViewById(R.id.testView);
        textView.setTextSize(20);
        textView.setText(s);

You may find the layout and java source files here.