Hi,
before Nokia collapsed it could happen to get daily 30+ USD from Vserv ads
with a not so big JTME application portfolio...
So, it is more promising than the donation model then... :)
Br,
Zoltan
2016-06-02 22:22 GMT+02:00 Matthias Fehring :
> My experiences with donations:
>
> Many talk abo
sp/next Thursday/Thursday 23rd June.
From: devel-boun...@lists.sailfishos.org [devel-boun...@lists.sailfishos.org]
on behalf of Chris Adams [chris.ad...@jolla.com]
Sent: Friday, June 03, 2016 10:57 AM
To: Sailfish OS Developers
Subject: Re: [SailfishDevel] [Minute
Hi,
Just a quick note about the time of the next meeting - if it was decided to
allow GMT+10 folks like me attend more easily: next Thursday night I'm going to
a Karnivool concert at the Triffid so I won't be able to attend the SFOS OSCCM.
Sorry for the hassle!
Cheers,
Chris.
___
My experiences with donations:
Many talk about but only really few do really donate. But this few mostly
donates more as I would charge for selling the app.
For example, I had ocNews as paid app in the Ovi Store for Meego and I think
it was in a price range of 1,99€ for Germany (other countries
I receive donations from 1/100 users...
I was also planning to change to inApp Payments...
Dylan
Original Message
Subject: Re: [SailfishDevel] Open source in-app ad API helper for QML - please,
join
Local Time: June 2, 2016 8:27 PM
UTC Time: June 2, 2016 6:27 PM
From: scooters
Some experiences from me as a former iOS Developer:
- With a good payed app, one can earn a some money
- A free app with InApp Payment for more features leads to more revenue on
my apps
- iAd leads to almost no revenue. On iOS one need several thousends of App
installations to get just a little re
Ahoy everyone!
Thanks to all who attended today's meeting.
Meeting minutes can be found here in a variety of formats:
Minutes:
http://merproject.org/meetings/mer-meeting/2016/mer-meeting.2016-06-02-13.30.html
Minutes (text):
http://merproject.org/meetings/mer-meeting/2016/mer-meeting.2016-06-0
I'm not sure but think it's a triple store, so a rudimentary one. On
Sailfish it seems to be intended for more action, as there are a couple
of disabled stores in there...
On 02/06/2016 2:42pm, Tone Kastlunger wrote:
In a distributed fashion it may make sense;
speaking of which, doesn't tracke
In a distributed fashion it may make sense;
speaking of which, doesn't tracker implement a graph db?
On Thu, Jun 2, 2016 at 3:40 PM, Andrew Branson
wrote:
> I'm missing how your contacts can be linked as a graph on your phone. I
> assumed it was about which of your friends know each other, but t
I'm missing how your contacts can be linked as a graph on your phone. I
assumed it was about which of your friends know each other, but that
isn't relevant information on the client side. I don't think it's even
easily available in the main social networks.
Andy
On 02/06/2016 2:34pm, Tone Kas
On the RDBMS vs Graph DB's discussion, the point Peter is making is a very
solid one;
the purpouse of the contacts app is to mange contacts; hence how they are
connected;
if relying on a Graph DB provides a simpler implementation (in terms of raw
lines of code I mean) in upper implementation levels
Hi!
RDBMSes are not very good at graphs, or trees, or any other data
structure that requires variable traversal steps in queries. I don't
think we have that here though. Those social networks only have graphs
when they're integrating your data with other people's, but personally
you just have
Well SQL is in my opinion good for grouping or conduct calculations on
transactional data.
Updating, or adding / sorting is not is best discipline. It is medicore in
my opinion.
On small sets of data as used in phones medicore performance is still
quick. Phones are quite powerfull today.
However
Peter;
I'm curious, what brings you to the conclusion SQL (as in relational dbs)
is not ideal for transactional functionality?
On Thu, Jun 2, 2016 at 10:41 AM, Peter Kovacs wrote:
> I would actually like to know why SQL stuff.
> Datastructure types I am think of on the Phone are relationships (F
Hi Peter,
All of this is just my opinion, and not necessarily representative of the views
of Jolla.
The reason is that SQL is simple, maintainable, and performant.
Yes, there are some edges which need to be handled carefully, but in general,
sqlite is the perfect solution for this type of data.
Hi Tone,
There is an intermediate stage (using an mkcal-backed QtOrganizer engine, to
provide read/write access to the mkcal backend data via QtOrganizer apis) which
wouldn't require any changes to the jolla-calendar application (or the various
sync adaptors we have currently).
But if we event
I would actually like to know why SQL stuff.
Datastructure types I am think of on the Phone are relationships (Facebook
style) or transactional.
And both are not ideal to solve with relational dbs.
I guess the Answer is because every one does it. But that is not really
satisfactory. Would there b
Hi Chris;
>2) API to access Calendar data. Correct, currently we don't provide
access to calendar API in Harbour. The reason is that we want to use
QtOrganizer as the public API, but to do that we need to write a
QtOrganizer engine backend >for mkcal (note that one already existed in
QtMobility
18 matches
Mail list logo
