Maybe an option to share sources to jolla QA or even letting them to
build application from sources and uploading to store to be 100% sure in
usecase?
On 25.12.2013 17:08, christopher.l...@thurweb.ch wrote:
Hi Bernd
Thanks for your interest.
I understand that there is a strong need to prevent apps that send
SMSes without the user's consent (a security issue), or to premium SMS
numbers, thereby defrauding the user.
But we should not throw out the baby with the bathwater. There will be
apps where SMS sending / handling is a primary part of the use-case,
and where the user willingly consents to each SMS being sent by that app.
My own use-case (simplified) is this:
My main hobby is paragliding. Mostly we land close to where we started
(at the foot of the mountain), but sometime we go cross-country and
land many kilometres away, and need to communicate back to a recovery
team the GPS location of the landing site.
The secondary use-case (secondary only because it should be far less
often used). Is the emergency situation. You have landed in a tree, or
as happened to me at the start of this year, are stuck on a cold and
snowy mountain slope with darkness approaching. Here you need to alert
the recovery team with your location, and the fact that your status is
NOT OK.
My app uses GPS and SMS to achieve this. Before flying the user sets
up a number of SMS templates (basically pre-filled messages to which
GPS coords will later be added. On landing the user fires up the app,
which starts the GPS. Once the GPS has acquired a fix, the user can
then chose between "Ok" and "Status NOT Ok" SMSes. Based on this
choice, the appropriate SMS template is taken, the GPS coords are
added to this, and a pre-selected contact associated with the SMS
template is chosen. The user sees both the text of the SMS, and the
chosen contact name and number.
At this point the user can press "send", and the SMS is sent to the
displayed contact. He also has the option of adding further text to
the SMS, and of changing the contact.
The aim is that he user should be able to send the SMS with an
absolute minimum of button presses, either because he may be tired (Ok
Situation), or because he is tired / injured / cold / wet (Emergency
situation). On the Harmattan version of the app I have one press to
open the app, a second to chose between Ok / Not Ok, and a third for
Send. In this case the phone may be being used at the limits of
touchscreen capabilities (cold and wet), so big buttons are called for.
It is in no way concealed from the user that the app sends SMSes:
Indeed it is the purpose of the app.
There are other apps out there with similar use cases. The Swiss
Helicopter rescue service REGA have one for iOS and Android.
Later I intend to make "the other half": in this case an app for the
Recovery team, that would pick incoming landed SMSes from pilots, and
display distance and bearing for each of these relevant to the
position of the recovery team.
Happy Christmas all.
Chris
Zitat von "Bernd Wachter" <bernd.wach...@jolla.com>:
<christopher.l...@thurweb.ch> writes:
Hi Bernd
Thanks, I am aware of that, but I think it is an inelegant solution,
acceptable ad interim as a workaround, but not longterm.
Allowing arbitrary applications to send SMS brings a big cost risk for
the user, due to all the premium SMS services out there -> it'll only be
possible once we enforce proper application permissions.
My app is designed for emergency use, must be easy to use as possible,
and therefore I require a larger send button. I know from personal
experience that trying to operate a mobile when it is wet and below
zero degrees is not easy (at the very edge of the capabilities of
touch screen technology).
Can you describe what exactly you're trying to do?
Bernd
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
