Sunday, 28 December 2014

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){
        Intent intent1=new Intent();
        catch(android.content.ActivityNotFoundException exception){

            //Do something else

Wednesday, 15 October 2014

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.

Monday, 8 September 2014

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.


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.

Friday, 1 August 2014

Alan Turing’s bibliography with links

The importance of the work of Alan Turing is well known to everybody. The most complete resources on Turing’s work are The Turing Digital Archive, the book “The essential Turing” of Jack Copeland and the volumes of his “Collected works”. The problem with the Digital Archive is that it contains scans of manuscripts from which is not so easy to read, yet I think it is very interesting to browse.
Below, I list most of Turing’s papers and some links for them. The links are freely accessible and they lead to easily read pdf files that are scans or reprints of the original publications or at least they are very close to it.
The links are listed as found on the web; any possible copyright issues or broken link issues should regard the owners of the sites that host the linked files. In case you have any suggestions for the list please add a comment.
At the end you may find something that should be an anecdote  but it is a real problem in academic publications.

Turing, Alan M. On computable numbers, with an application to the Entscheidungs problem. Proceedings of the London Mathematical Society, 2 s. vol. 42 (1936–1937), pp. 230–265.

Turing, Alan M. "On Computable Numbers, with an Application to the Entscheidungsproblem. A Correction." Proceedings of the London Mathematical Society 2.1 (1938): 544-546.

Turing, Alan M. "Equivalence of left and right almost periodicity." Journal of the London Mathematical Society 1.4 (1935): 284-285.

Turing, Alan M. "Computability and λ-definability." The Journal of Symbolic Logic 2.04 (1937): 153-163.

Turing, Alan M. "The þ-function in λ-K-conversion." The Journal of Symbolic Logic 2.04 (1937): 164-164.


Turing, Alan M. "Systems of logic based on ordinals." Proceedings of the London Mathematical Society 2.1 (1939): 161-228.

Turing, Alan M. "The use of dots as brackets in Church's system." The Journal of Symbolic Logic 7.04 (1942): 146-156.

Newman, M. H. A., and Turing, A. M. "A formal theorem in Church's theory of types." The Journal of Symbolic Logic 7.01 (1942): 28-33.

Turing, Alan M. "Turing’s treatise on Enigma." Unpublished Manuscript (1939).


Turing, Alan M. "Lecture to the london mathematical society on 20 february 1947." MD COMPUTING 12 (1995): 390-390


 Turing, Alan M. "Some calculations of the Riemann zeta-function." Proceedings of the London Mathematical Society 3.1 (1953): 99-117.

Turing, Alan M., and Bayley, D. "Report on Speech Secrecy System DELILAH, a Technical Description Compiled by AM Turing and Lieutenant D. Bayley REME, 1945–1946." Cryptologia 36.4 (2012): 295-340.

Turing, Alan M. "Proposed electronic calculator, report for national physical laboratory, teddington." AM Turing’s ACE Report of 2 (1946).

Turing, Alan M. "Lecture on the Automatic Computing Engine (1947)." The Essential Turing by  B. Jack Copeland (2004): 362.

Turing, Alan M. "Rounding-off errors in matrix processes." The Quarterly Journal of Mechanics and Applied Mathematics 1.1 (1948): 287-308.

Turing, Alan M. "Intelligent Machinery, A Heretical Theory." The Turing Test: Verbal Behavior as the Hallmark of Intelligence (1948): 105.

Turing, Alan M. "Intelligent machinery-national physical laboratory report. b. meltzer b., d. michie, d.(eds) 1969, machine intelligence 5." Edinburgh: Edinburgh University 2 (1948).

Turing, Alan M. "Practical forms of type theory." The Journal of Symbolic Logic 13.02 (1948): 80-94.

Turing, Alan M. "Computing machinery and intelligence." Mind (1950): 433-460.

Turing, Alan M. "The word problem in semi-groups with cancellation." Annals of Mathematics (1950): 491-505.

Turing, Alan M. "THE CHEMICAL BASIS OF MORPHOGENESIS." Philosophical Transactions of the Royal Society of London. Series B, Biological Sciences 237.641 (1952): 37-72.

Turing, Alan M. "Chess." Computer chess compendium. Springer New York, 1988. 14-17.

This article is a reprint of pages 286-295 from

B.V. Bowden ( ed.) Faster Than Thought ( A Symposium on Digital Computing Machines ) Sir Isaac Pitman & Sons Ltd. 1953.

The original book in text and pdf form may be found here

Turing, Alan M. "Solvable and unsolvable problems." Science News-ens. fr 39 (1954).

A paper by     Verónica Bechera, Santiago Figueiraa  and  Rafael Picchia  presenting the unpublished work of Turing in normal numbers

Becher, Verónica, Santiago Figueira, and Rafael Picchi. "Turing’s unpublished algorithm for normal numbers." Theoretical Computer Science 377.1 (2007): 126-138.

Turing, Alan M.. AM Turing's Original Proposal for the Development of an Electronic Computer: Reprinted with a Foreword by DW Davies. National Physical Laboratory, Division of Computer Science, 1972.

Turing, Alan M. "Proposal for development in the mathematics division of an automatic computing engine (ace)." Carpenter, BE, Doran, RW (eds) 46 (1986).

Turing, Alan M. "Checking a large routine." The early British computer conferences. MIT Press, 1989.
The next should be an anecdote; it is not. In the link below of the article written by Simone Santini, you may read some negative reviews that some incredible reviewers gave to some of the most important papers ever written. One of this papers is Turing's most famous paper.