Andrey
That solution would be perfect for me, I would have no problem with
supplying the code. The sources for the Harmattan version are out
there on Github already, and the Sailfish sources soon will be.
In theory it might even be possible to separate the SMS bit of my app,
including the control used to display the text, name and number + send
button into a separate shared library C++ that would be called by my
app. My app would simply provide the SMS body and the name of number
of the chosen contact, and the library would take care of the rest.
This would reduce the amount of code that would need to be audited.
(At the moment the GUI bits are QML, I would need to do some thinking
about how to move these to C++)
Chris
Zitat von "Andrey Kozhevnikov" <coderusin...@gmail.com>:
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
_______________________________________________
SailfishOS.org Devel mailing list
