[Android-development] On False Promises ...
Rubi Mazaki
rubimazaki at gmail.com
Mon Jan 6 17:21:05 CET 2014
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>
More information about the Android-development
mailing list