[Android-development] On False Promises ...

[Rutledge Shawn]

On 6 Jan 2014, at 1:29 PM, Rubi Mazaki wrote:

> I than found that, the controls in the applications look very small, 

Which device do you have?  I know there are some problems with font scaling, but on the larger-screen devices the fonts tend to be too large.  The problem has been mainly disagreement about how font sizes should be specified and scaled.  The majority seems to believe that in general, fonts should be smaller on smaller devices, because you compensate by holding the device closer to your face.  And yet some people always complain that fonts are too small.  This has been true for the entire history of computing, AFAICT.  Yet if you make the fonts too large, the fact is that you cannot display enough information in one screenful, and that is also frustrating.  So IMO there should always be a system-wide zoom factor, to suit different people in different age groups.  There is one on Android, but it's not very fine-grained, and I'm not sure if Qt is doing the right thing with it.  We could at least hope to have the same result if a font size is set with the same value and the same units in Qt vs. in a native Java app.

Anyway having real-world units (e.g. being able to specify font size 3mm) would depend on having accurate pixel density information available on every device; I'm not sure if it's dependable yet.  I wish that we could guarantee it; I don't see any other viable long-term solution, because pixel density is extremely variable nowadays (from 100 to over 400 DPI).  But some PC monitors and TVs fail to tell the truth about their own pixel density.  (And many will say that the TV actually should tell lies, because you always look at it from a distance.  But as soon as devices start telling lies, it's difficult to predict what exactly you will get, because different manufacturers will of course tell different lies.)  On iOS the information is not even available; only the model of device is available, and so far it's a short enough list that we know the density of the display on each device.  But Apple wants developers to assume 144 DPI on every "retina" screen and 72 DPI otherwise.  Mainly because when it comes to raster image assets, it's easier to either redo them at 2X resolution, or keep using the ones that were designed for 72 or 100 DPI.  But to keep it all proportional, this assumption means we don't quite get the benefit of fully-scalable fonts and vector graphics.  So if you have an iPad mini, I guess they expect that you have to hold it closer to your face than if you have a full-size iPad, to achieve the same readability.  Qt usually tries to follow platform conventions, so we have the same 2x concept on Apple devices.  But I don't like it, and IMO taking the same approach on Android is not viable because there is so much more variation in densities on different devices.  So the meaning of a "point" has become inconsistent lately, even though most applications specify font sizes in points; and we are left with conflicting opinions about what is a reasonable scale, and about how to achieve it.  For now, if you want a real-world font size in your application, it's possible to choose a font size in mm, multiply by Screen.pixelDensity and set font.pixelSize, rather than setting font.pointSize.  It will work as long as Screen.pixelDensity is really correct.  But our examples don't all do that.  It's cumbersome, doesn't seem like the right solution, doesn't take the user's chosen zoom factor into account, and you might not get what you ask for on certain screens anyway.

> and that the photo-surface sample could not access any photo on my phone. It started in the wrong (apparently) folder, and after trying to navigate through the directories I got the application stuck after 5 attempts. I didn’t see a single photo …
> 
> Ok, I told myself. I am strong. I am potent. I can do it .. or not..
> 
> I looked up in the internet, and found that I could merge in an AndroidManifest.xml file. Maybe if I would set the permissions, the sample would finally work!
> I didn’t find too many places describing how to set my custom AndroidManifest.xml into the .pro project file. But I pushed harder, and I found that if you specify the source directory for the AndroidManifest.xml than you could get it to work. After some trial and error, I setting up all of the available android permissions to the sample. I even checked on the application menu of the phone, and the permissions where successfully set. All the 350 of them :)
> 
> It didn’t help though.. It still didn’t show any photo, and I still could not browse to the right folder…
> I gave up on that sample, and tried a few more others.

I'm sorry for your experiences with that test and with the file dialog.  I confess that it needs a bit more research, how file permissions work on Android, which folders can be available, how the dialog should navigate only to folders that you actually have permissions for, and how it could provide better, friendlier links to navigate to the folders where you most likely will want to go.  The dialog might need to look different on different platforms.  It seems the PhotoSurface app might need <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" /> in order to access the photos.  If anyone has any further enlightenment about file access permissions and best practices, please let us know.  And BTW iOS doesn't give you much permission to navigate either; but file dialogs and data sharing between applications have been really uncommon on that platform so far.  At least I do hope to have a more usable file dialog implementation in 5.3.0.

I suppose more typical applications would be interested in accessing files of their own type, which they created themselves.  So by default an application stores its own data in its own directory and doesn't need to see other directories.  But the overall experience on every mobile device to date reminds me of some ranting about the inflexibility of application "silos" back in the 80's and 90's on PCs, and the need to break down barriers and build document-oriented systems rather than application-oriented ones; but the solutions for sharing data between applications that were actually developed then went way beyond what has been done on mobile devices so far.  The apps are like the scary kind of shareware from those days too: users can't trust them (even if many users don't know that they can't), so it's actually appropriate that the apps can't see each others' data by default, without permission.  And the permissions model doesn't give you enough control; as a user you're expected to decide whether you're going to trust the app or not.  Any time there's a popup asking whether this app can do that operation, it's an annoyance.  The need for distrust and isolation detracts from the platform for both users and developers.  There's only so much we can do to mitigate it.

> 1. Downloads can be put to torrents. Even with open source resources – Let some people be the “torrent keepers” (I volunteer my home connection at day time..) use uTorrent and leave the downloads open.

I think we should seed official torrents as soon as a new version is available, and provide links on the download page.  It's been discussed, but hasn't happened yet.

> 2. Add Android installations (sdk/ndk) into the Android installer. Make it setup the paths right to the environment.

It sounds heavy-handed to include it.  But maybe the installer could try to find the existing one and at least nag the user to download it if it can't be found.  You could write up a bug about that too if you like.

I'll let others comment on the Creator-related issues.