On Wed, Jan 20, 2010 at 8:39 AM, alandgri wrote:
> So it sounds like what we need is more accountability on the part of
> handset makers and carriers to provide reliable customizations and
> drivers and to regularly update their devices.
Accountability? In what way do you think it's possible to
So it sounds like what we need is more accountability on the part of
handset makers and carriers to provide reliable customizations and
drivers and to regularly update their devices.
My thought is to provide better information which should enable
transparency and accountability. In addition to t
On Jan 20, 3:06 am, Christine wrote:
> Let's not whine.
Well yeah
> Android is a new platform, manufacturers are trying
> out business models,
Let's remember Android/SDK is around longer than the iPhone SDK or Web
OS. Let's not try to rationalize apologies for others either.
> they experiment
Let's not whine. Android is a new platform, manufacturers are trying
out business models, they experiment with hardware and software, but
I'm sure that the world will converge towards a platform that will
allow us to write apps for all phones that run Android, give or take a
few phones that are "di
On Jan 20, 2:13 am, Kevin Duffey wrote:
> market app? Hell, open source that sucker and let us contribute to it.
+Long.MAX_VALUE
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-develope
I suppose it's too late, or perhaps too many wouldn't have joined up with
google if they had done this, but it would have been nice if there was a
guarantee from all devices that any app that runs on the emulator will run
on devices. I've read not just in these emails, but on other forums as well
t
I'm not alone when it comes to the updating issue, check this article
out "Android’s Next Challange? iTunes | Linux Magazine - http://goo.gl/gPzw";
However as Dianne explained yesterday there's not much Google can do
about this, since only manufacturers can release the updates for the
phones, afte
Couple thoughts on this. TreKing has a good idea. I've seen this done
before. The only thing I would be worried about is as a user of the app,
having to pass thru all this content to get to the app. Sure, you probably
allow them to skip it. A different idea.. is this even worthy..is to provide
a li
On Tue, Jan 19, 2010 at 2:31 PM, TreKing wrote:
> 2 screenshot limit ...
No option for landscape orientation on those two screen shots either.
To assume everyone will build a portrait oriented app is very short
sighted.
> 3 - Reminds users that there are so many variations of phones and Android
Very interesting thread so far. I completely agree with the sentiment that
continuing to develop and support an app on Android with all the differences
in platforms and versions available is making a developer's life difficult.
Especially with the complete lack of basic but essential functionality
Check google for "Android Remote Stacktrace".
On Tue, Jan 19, 2010 at 12:41 PM, Laszlo Szucs wrote:
> I think it would be a great help for the developers to create an
> Automated Crash Report System for published applications.
>
> When an application crashes, and the message dialog pops up with
I think it would be a great help for the developers to create an
Automated Crash Report System for published applications.
When an application crashes, and the message dialog pops up with the
famous "Force Close" button, there could be one another button with
text: "Send Report", like in other app
This may be slightly off topic,
But still the google team should look at expanding the android market
to different countries.
Seems apple now has nearly 97% of all mobile application downloads.
When the spp store wasreleased apps were available in around 80
countries and for around the same nu
I think there is a fairly easily implemented solution to the problem
of device and OS diversification. I've been using this myself for
months and it works very well.
For "Radar Now!" I've established a "beta" test community of users who
have volunteered to try out new versions of the app and even
>
> Problem is, half the time we don't know. Users post 1* Market comments
> saying "Force closes on Droid" or "Doesn't work on Samsung Moment",
> and unless you have that specific handset to test on, you're SOL. You
> "sanity check" on an emulator instance of the same resolution and OS
> version,
String,
Thank you for taking the time writing this up. Five stars. I just feel
stupid every time I get on the soapbox just to rehash what should long
have been addressed by Google/the Android team.
I have no idea how to get this across. Diane, Romain and who else from
the other side who have been h
Device diversity is both a blessing and a curse. For the variety of
reasons already mentioned, even a well-designed infrastructure is not
going to provide absolute confidence that apps will work on
'compatible' devices that haven't actually been tested. 10 years ago
we saw the same problem with WAP
That's what I'm talking about !
We do not know, where problems are, when software works on "clean
Android" and do not works on some devices.
For example: Hero's UI's is BUGGY as hell (for example, keyboard
events are not fired correctly).
Another example: why Samsung's GPS is working not the sam
On Jan 19, 12:50 am, Dianne Hackborn wrote:
> Specifically which problems are you having?
Problem is, half the time we don't know. Users post 1* Market comments
saying "Force closes on Droid" or "Doesn't work on Samsung Moment",
and unless you have that specific handset to test on, you're SOL. Y
On Mon, Jan 18, 2010 at 3:29 PM, Piotr wrote:
> I tried to fix some problems with my app on new devices. But you can't
> bugfix, without real device, when your app works on all emu possible
> SDK's without problems.
>
Specifically which problems are you having?
--
Dianne Hackborn
Android frame
You are f** right. And I'm just ungry.
Android is going stright forward J2ME way - milions of devices,
thousands profiles, screen sizes, controls, etc..
I think, the biggest Java/Android advantage - one code for all devices
is slowly vanishing.
I tried to fix some problems with my app on new dev
On Jan 18, 2:29 pm, Greg Donald wrote:
> On Mon, Jan 18, 2010 at 4:18 PM, JP wrote:
> > At least as far as the argument of screen sizes is concerned -
> > personally I don't count that as an argument in support of
> > fragmentation or anything. At least in that regard someone had the
> > foresi
On Mon, Jan 18, 2010 at 4:18 PM, JP wrote:
> At least as far as the argument of screen sizes is concerned -
> personally I don't count that as an argument in support of
> fragmentation or anything. At least in that regard someone had the
> foresight to anticipate this coming the emulator offer
On Mon, Jan 18, 2010 at 3:54 PM, Dianne Hackborn wrote:
> There is absolutely no need for you to turn that into a matrix and test
> every combination. Do you work on 480x854 screens? Great, you have that
> covered regardless of the platform.
But not hardware, different phones behave differently
And we've warned developers many times to use the dip unit, to not
hard code coordinates, etc.
On Mon, Jan 18, 2010 at 2:18 PM, JP wrote:
>
>
> On Jan 18, 1:41 pm, Greg Donald wrote:
>
>> Screen Resolutions:
>>
>> 320x480 - 45.85%
>> 480x854 - 31.74%
>> 480x320 - 16.69%
>> 854x480 - 3.73%
>> 480
On Jan 18, 1:41 pm, Greg Donald wrote:
> Screen Resolutions:
>
> 320x480 - 45.85%
> 480x854 - 31.74%
> 480x320 - 16.69%
> 854x480 - 3.73%
> 480x800 - 1.15%
> 800x480 - 0.24%
>
> Four or five SDK versions multiplied by three or four screen
> resolutions makes testing an infinitely long t
On Jan 18, 12:45 pm, Dianne Hackborn wrote:
> On Mon, Jan 18, 2010 at 11:58 AM, JP wrote:
> > >http://android-developers.blogspot.com/2009/04/backward-compatibility...
> > This means having to cut off users on older Android releases, no?
>
> Um. No? The entire article is about how to use newe
There is absolutely no need for you to turn that into a matrix and test
every combination. Do you work on 480x854 screens? Great, you have that
covered regardless of the platform. And if you support 480x854, you must
have already tested 854x480, since any device can be switched between
landscape
On Mon, Jan 18, 2010 at 3:10 PM, Christine wrote:
> It's good to see Google staff take this issue seriously :-)
Yeah, right.
> I'll repeat my personal opinion that fragmentation will not be so much
> of an issue, unless you desperately need 2.x features in your app, in
> which case you'll have t
On Mon, Jan 18, 2010 at 1:04 PM, Alberto wrote:
> Dianne: I understand the issue with manufacturers and drivers, but
> even if manufacturers have to prepare the updates for each handsets,
> wouldn't be possible for Google to distribute those updates through
> their own channels instead of going t
It's good to see Google staff take this issue seriously :-)
I'll repeat my personal opinion that fragmentation will not be so much
of an issue, unless you desperately need 2.x features in your app, in
which case you'll have to accept a <1% market share of your app.
On Jan 18, 9:45 pm, Dianne Hack
On Mon, Jan 18, 2010 at 2:32 PM, Dianne Hackborn wrote:
> Actually I am seeing a lot of positive change in this regard -- most of the
> major manufacturers (HTC, Motorola) seem to have publicly stated that they
> will be delivering a significant update to their current devices.
Public statements
Exactly, some carriers won't go through the trouble of doing OTA
updates, your Android experience would vary depending on what carrier
you're. Also when I talk about fragmentation, I'm not just talking
about apps compatibility, but also the user experience is very
different from 1.6 to 2.1, some pe
On Mon, Jan 18, 2010 at 11:58 AM, JP wrote:
> > http://android-developers.blogspot.com/2009/04/backward-compatibility...
> This means having to cut off users on older Android releases, no?
>
Um. No? The entire article is about how to use newer APIs while remaining
compatible with older platfor
On Mon, Jan 18, 2010 at 12:14 PM, JP wrote:
> Exactly. That's how they operate. Kindof enticing when you're a dev.
> Crank it out, push it to the consumer, hope it runs and if there's
> nothing major (like Rogers' 911 issue), leave the code behind and move
> on to the next thing.
>
Actually I am
On Mon, Jan 18, 2010 at 10:57 AM, Kevin Duffey wrote:
> Good reply Dianne. I get pissed when I read blogs about how fragmented
> Android is as well. I don't get how it's fragmented. The only fragmentation
> that seems slightly just is the issue where individual phone vendors are
> providing their
Exactly. That's how they operate. Kindof enticing when you're a dev.
Crank it out, push it to the consumer, hope it runs and if there's
nothing major (like Rogers' 911 issue), leave the code behind and move
on to the next thing.
On Jan 18, 12:03 pm, Greg Donald wrote:
> On Mon, Jan 18, 2010 at 1
On Mon, Jan 18, 2010 at 1:58 PM, JP wrote:
> It's unfortunate that some of the carriers and manufacturers haven't
> caught on to the idea of bringing their products along for the ride,
There's no incentive. The (phone) sale has already been made, why on
earth would they then want to also support
On Jan 18, 10:35 am, Dianne Hackborn wrote:
> On Mon, Jan 18, 2010 at 7:22 AM, JP wrote:
> > Hmm, I've toyed with that a while back, and as far as I remember, the
> > app won't even launch, and crash with a class-not-found exception
> > (makes somewhat sense).
>
>
> http://android-developers.bl
Good reply Dianne. I get pissed when I read blogs about how fragmented
Android is as well. I don't get how it's fragmented. The only fragmentation
that seems slightly just is the issue where individual phone vendors are
providing their own special UI and extra features. I think the biggest issue
th
On Mon, Jan 18, 2010 at 7:22 AM, JP wrote:
> Hmm, I've toyed with that a while back, and as far as I remember, the
> app won't even launch, and crash with a class-not-found exception
> (makes somewhat sense).
>
If you just do things correctly, it is fine. And correctly means: make sure
that the
Hmm, I've toyed with that a while back, and as far as I remember, the
app won't even launch, and crash with a class-not-found exception
(makes somewhat sense).
AFAIK, you cannot slide in dummy classes in Android's namespace work
around that either. Or did I miss something?
On Jan 18, 2:48 am, Chri
I believe that maxsdkversion has already been or is in the process of
being depreciated, meaning the market no longer looks at that tag in
the manifest. Which makes sense because if the OS updated to a newer
version but not all the apps did, they would dissapear in the market
to that user, despite
I agree with Mark that older apps, like 1.6 apps, run "happily" on
newer sdks. Most apps can do without the newer features, if you accept
that sometimes you have to do more work, or the feature you build is
slightly less attractive. Or, you can have a Factory class that
returns the right version cl
What I said is that you _can_ specify that a user sees only the one
relevant version of your app in the mp. The mp _does_ read
minsdkversion and maxsdkversion.
On Jan 17, 11:14 pm, Kevin Duffey wrote:
> Man..now that sucks. That is a bug if you ask me.. the market should NOT
> show a 1.5 users a
That's how it works.
You can have only *one* version of an app. Your app's ID is determined
by its package-name. The code in your app should be able to run on a
phone with an OS equal to minSdkVersion or higher.
You can specify that your app only supports (i.e. runs on) a certain
number of SDKs:
Man..now that sucks. That is a bug if you ask me.. the market should NOT
show a 1.5 users a 1.6 SDK app update. That's just pure stupidity. That
makes no sense at all and I am shocked and disturbed that this is how it
works. They basically want you to submit a brand new 1.6 app so that 1.5
users do
On Jan 17, 9:26 pm, Kevin Duffey wrote:
> First.. let me ask for those of you that have apps in the market.. if I have
> a 1.5 version out there.. it shows up on any device that is 1.5 or later,
> right? Now..if I update it to run on 2.0.. will the update be made available
> or even notify 1.5/1.6
1) It depends on your Manifest.xml file, if your minSdk is set to,
lets say 4 (1.6), then new users on Android 1.6 and above will be the
only ones that see it. UNLESS, users on 1.5 already had your app (it
shows as installed, or purchased), then those users on sdk 3 (1.5)
will still see it and be a
First.. let me ask for those of you that have apps in the market.. if I have
a 1.5 version out there.. it shows up on any device that is 1.5 or later,
right? Now..if I update it to run on 2.0.. will the update be made available
or even notify 1.5/1.6 users? Or does it only show up for 2.0 and later
The fragmentation problem is mainly with the newest APIs, and
applications taking advantage of them.
Official, or supported APIs barely change, and if they do, the older
API is backward compatible.
Take for instance the contacts API before 2.0 (Contacts.People), and
the newest (ContactsContract) t
Marks right, generally things work well. Although there do appear to
be some differences between handsets in terms of their openGL support
- seems like droid has some issues with png formats (at least from
what I've seen on message boards)
On Jan 17, 2:35 pm, "Mark Murphy" wrote:
> > It might ev
52 matches
Mail list logo
