Permissions on Android are tricky to get right from a user perspective. Usually you only want to do something minor and innocuous (pre-fill a form with a contact’s info) but the actual permission you have to request gives you much more power than necessary (access to ALL contact details, ever).
It’s understandable that users might be suspicious of you. If your app is closed-source then they have no way of verifying you’re not downloading all their contacts to their servers. Even if you explain the permission request people may not trust you. In the past I’ve chosen not to implement what might be handy features just to avoid user distrust.
That said, one thing that bothers me is that you don’t always have to ask for permission to do some actions.
Exactly, because on Android, you can use Intents.
Android’s Intents system is fascinating from a historical perspective. Like so many other aspects of smartphones we take for granted today, it comes from PalmOS (and not from iOS or Android). I detailed PalmOS’ “multitasking” capabilities in my Palm retrospective, but it basically comes down to this: in PalmOS, applications could ‘sublaunch’ other applications, let them do stuff, and then return to the original application. Many of the people working on these PalmOS capabilities (some of whom came from Be) would later work for the Android team at Google, where they further evolved it into the Intents system Android currently has.
The current smartphone platforms owe way more to Palm than modern pundits will ever be capable of understanding or willing to admit. Want to talk about inconsequential crap beveled edges and rounded corners some more?
1. Beam files AND applications wirelessly to another Palm user
2. Wireless synchronize to a PC, or do so over a network or modem.
3. Touch input
All running on a 16Mhz processor!
The intent system worked wonders with the “card stack” metaphor that early Android was built around.
but things got decidedly jumbled with 3.x and the Fragments framework. Now all of a sudden you had one “card” sitting as the sidebar of other “cards”, and you got the top right “up” interaction in addition to the back button.
End result is that i have seen Fragments apps that will take you back the whole interaction history if you start tapping the back button (file managers are particularly notorious).
Not that the current Material design is much better. Now you have the “burger” menu that slides in the sidebar “card” from Fragments, and if you try to use anything but a portrait phone you get a whole mess of wasted space. Space that can’t even be used as a safe scrolling areas for some brain dead reason.
Meh, the “best” version of android may have been late 4.1. at least then there was a proper tablet UI going round, rather than a phone UI with the basic buttons at the bottom rather than the side…
All in all, i get the feeling that there are too many design metaphors running around in computing these days.
I get the feeling that people spend too much time bitching about design metaphors these days.
Because you know
It’s all about that Palm
‘Bout that Palm, no Android
It’s all about that Palm
‘Bout that Palm, no Android
It’s all about that Palm
‘Bout that Palm, no Android
It’s all about that Palm
‘Bout that Palm
The BlackBerry 10 invocation framework works very similar.
An application can not only delegate viewing or editing of data to an application but also delegate “picking”.
E.g. you could write an email program that did not need access to either the addressbook or, say, the gallery, and still be able to compose a message to anyone in the addressbook and attach any image the user would like to.
There is a similar mechanism discussed/implemented for sandboxed Linux desktop apps as far as I understand.
Okay – I’ll admit I never used PalmOS much past V3.5, but as someone who actually developed a few apps for the classic Palm API, NO!! PalmOS allowed via the API for an app to launch and close and as part of the launch, it could do some kind of processing – but this has absolutely no commonality with Intents, nor does it work even vaguely like it does in Android. The App which launched the other process was suspended and closed (PalmOS 2.x and 3.x only has one active app at a time, not sure about later versions) and the App you launched more or less needed to be hard coded in to your app, as you needed to know the specific app Id to launch it. You couldn’t just say “I want an app that handles DOC files” from what I recall.
The Intents system is closer to how BeIA worked, indeed it used/uses the same Binder API (does it still?) which was originated in BeIA and BeOS post R5.03 for the IPC mechanism.
The developer who actually worked on both systems for both companies seems to disagree with you.
tl;dr – I was correct with in the parameters of my experience, and what they added looks like it extends what you could already do in a slightly more generic way. But what you could already do was not very innovative as it was pretty much only an app/process chaining mechanism. I have no idea how they actually implemented it though, so I expect the newer API was a lot slicker and less painful to use.
Long form: Which version of PalmOS though? Like I said, my experience pre-dates the ARM stuff they introduced in later versions. You seem to want to lump all PalmOS in to the narrow section you experienced, where as there were devices from 1996 right up to fairly recently and the older devices and newest devices shared a common API with its roots in the original PalmOS 1.0… just because PalmOS eventually did something, doesn’t mean it always did it that way and that is what seems to be left out of your “PalmOS was first” congratulatory rhetoric most of the time.
In the classic API, you could launch any app from any other app, but the flags you passed dictated how it actually launched. But you passed control from one app to another, even when you didn’t launch the other app far enough to get the GUI.
A quick flick through these docs make it look like that API was still supported in 5.x:
https://stuff.mit.edu/afs/sipb/user/yonah/docs/Palm%20OS%20R…
Look at the section entitled “Launch codes”.
Also:
http://www.cs.uml.edu/~fredm/courses/91.308-fall05/palm/Palm%20…
Look at page 27, “Launching apps programatically”.
That is how PalmOS alarms etc worked. The app registered some kind of system wide API hook that was periodically called and the app launched briefly to process the data being passed to it. It was really as primitive as that sounds. This was 1998 – 2002 time frame. PalmOS 2.0 – 3.5. I never used anything newer than that because PalmOS was too restrictive for the work we were doing. Everything was either custom hardware, EPOC or WindowsCE after that.
It looks like 4.0 added in the “Helper API”, but with a massive caveat that it might not be supported on all devices. That was well after I stopped caring about PalmOS. It looks like a bit of an extension to what was already there. It must never be understated that what was already there was a massive hack though. It was a more generic interface to an established protocol, so I don’t hold this up as some kind of magic turning point at all, it’s just a revision of a very old concept. A concept that existed well before PalmOS existed – pretty much the same type of mechanism most co-operative multitasking OS used for inter app comms.
Oh, and reading Dianne’s post, she seemed to be talking mainly about Cobalt, which yeah, totally used exactly the same IPC mechanism, Binder. You and I have never seen a Cobalt device, come on, no one ever did. I almost wished I’d read the post from your link first as I’d have saved about 10 minutes Googling the API’s and remembering how god-awful the Palm API was.
If the app is open source, you STILL cannot verify that the BINARY running on your device, distributed through the Play Store is not doing all kinds of nefarious things. This is the same problem with electronic voting machines – it doesn’t matter a lick whether it’s open source or not.
Why don’t people get that?