[Android-development] On False Promises ...

[Rubi Mazaki]

Hi Rutledge,

Thanks for ready and answering - let me answer inline:

On Mon, Jan 6, 2014 at 5:31 PM, Rutledge Shawn <Shawn.Rutledge at digia.com>wrote:

>
> 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.
>




*I am using Samsung Galaxy II - I purposely bought a smaller screen device
than the new Samsung S3/4 devices, because I don't like the phone to be so
big. As I answered to the above mail - I think native UI is very important,
and is supported by other (competing) frameworks. Most of these frameworks
are just faking the Native UI in JS. So I guess QML can do here as well. *




>
> 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.
>

*That would be great! *


>
> 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.
>

*I agree that the mobile/Android data store can be confusing. And, if I may
add a hint of my knowledge - A data store should always be divided to
secure and insecure (or less secure). In android, and as was also in
Symbian (where I used to swim :) - the sdcard/removable media is not safe,
and usually not even encrypted, while the local memory is encrypted and
unreachable outside of the user/process/application scope. I believe this
is also the design in iOS, although I have no experience there. So data
stores in a mobile app should always be available in these 2 forms
(safe/non-safe - in the application context).*


>
> > 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.
>

*A torrent is a very easy free way to support high speed downloads. Current
state of the mirror downloads is VERY VERY slow. about 1/100 slower than
comparable downloads (e.g. sourceforge.net <http://sourceforge.net>
downloads..)*


>
> > 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.
>




*This really should not be a big issue - just open a browser with a url in
it.. Let the user do that!I will file a bug related to that later on.*

*Thanks!Rubi*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/android-development/attachments/20140106/76799ab4/attachment.html>