On May 31, 12:59 am, Nikolay Elenkov
wrote:
> Hm, I'm definitely getting different UIDs for apps signed with the same key:
Sorry, I read things wrong. What's more interesting is that if the
package trying to read preferences from another package and they don't
have the same user id, the first pa
On Tue, May 31, 2011 at 4:01 PM, Doug wrote:
> On May 30, 7:09 pm, Nikolay Elenkov wrote:
>> On Tue, May 31, 2011 at 10:54 AM, String
>> wrote:
>> > In any case, I would agree that expecting them to synchronize between
>> > processes in real time is, um, unrealistic, but they definitely do work
On May 30, 11:27 pm, Chris wrote:
> Most of my traction came from overseas. Fragmentation is an issue (I really
> want to drop support for Android 1.x) and I'm guessing I'm going to be
> supporting a "final" free version forever.
You can make it clear to your users that you will support certain
On May 30, 7:09 pm, Nikolay Elenkov wrote:
> On Tue, May 31, 2011 at 10:54 AM, String
> wrote:
> > In any case, I would agree that expecting them to synchronize between
> > processes in real time is, um, unrealistic, but they definitely do work for
> > the simple case of one app being able to re
I already have an export to SD, import to whatever version design so even if
I had to force them to install a new app it'd be easy. I'm mostly worried
about what the conversion rate might be. My app is based on long-term data
storage and analysis, so old users who simply can't upgrade (eg, due
On Tue, May 31, 2011 at 10:54 AM, String wrote:
> In any case, I would agree that expecting them to synchronize between
> processes in real time is, um, unrealistic, but they definitely do work for
> the simple case of one app being able to read the prefs which another has
> written. Both apps ne
On Tuesday, May 31, 2011 12:45:00 AM UTC+1, Doug wrote:
On May 30, 2:19 pm, String wrote:
> > Yes. That's why they're called shared preferences.
>
> Um, I think they are shared SharedPreferences because there is one
> instance of a particular SharedPreferences object shared among all the
> co
On May 30, 2:19 pm, String wrote:
> Yes. That's why they're called shared preferences.
Um, I think they are shared SharedPreferences because there is one
instance of a particular SharedPreferences object shared among all the
components of an application.
Also, be careful with modifying preferenc
Yes. That's why they're called shared preferences.
String
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-deve
I'm not sure, but isn't it possible to directly access the shared prefs of
one app from another (by the same developer/publisher)?
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@goog
> Hi Chris;
> One way is to provide additional feature/function to the free app
> and then you can charge for the new version. This requires work
> but you have the advantage of having an existing user base.
> Sincerely,
> Kiet
No, you cannot. Once it's free, it's free forever (unless you use in-
Hi Chris;
One way is to provide additional feature/function to the free app
and then you can charge for the new version. This requires work
but you have the advantage of having an existing user base.
Sincerely,
Kiet
On May 29, 9:21 pm, Chris wrote:
> Hi there,
>
> So I started working with Androi
On Mon, May 30, 2011 at 2:47 AM, Peter Webb wrote:
> I don't know what you would do if you wanted to transfer (say) user
> preferences from the free to the paid, if that is your issue then you may
> need to do something clever ...
>
Export to SD card, re-import from paid version. Pretty straight
I have just made a paid version of my free app.
The only chnage I made to my free version was I included a market link
to my paid version.
My ratings dropped immediately. I used to get 65% of my ratings as 5
star, immediately dropped to less than 50%. This was nowhere made up
for by 5 start ratin
On Mon, May 30, 2011 at 2:54 PM, William Ferguson
wrote:
> You could offer an in-app purchase to upgrade users from your existing
> free app to whatever extra capability/content you believe they will
> pay for. That way you only have a single app, single source base.
>
Right. But currently there
You could offer an in-app purchase to upgrade users from your existing
free app to whatever extra capability/content you believe they will
pay for. That way you only have a single app, single source base.
On May 30, 2:21 pm, Chris wrote:
> Hi there,
>
> So I started working with Android a while
Hi guys , can you just mention any place where all the details regarding the
app hosting on android market is available ?
And can we host paid android apps on our website without anyones permission
??
On Mon, May 30, 2011 at 9:58 AM, Zsolt Vasvari wrote:
> They will HAVE to download a new app.
They will HAVE to download a new app. Each app is different and there
is no way of making a previously free app paid. So you will need to
change the package name and package name = app.
Personally, I just appended a "p" after my non-paid app name to create
the new package name.
Coincidentally,
18 matches
Mail list logo
