I'd welcome that too. For some reason my app's Listview-based menu
according to recent user reports breaks (crashes) on some phones, but
I cannot get it to break on my vanilla dev phone 1 (thus making it
very hard to track down and fix the problem). I'm not using any
private classes AFAIK, but
If you are not using reflection or not trying to use any non android.*
API or non android.R.* resource, then a compatibility check would not
help. The SDK *is* the compatibility check (except, unfortunately for
the case discussed in this thread before.)
On Tue, Feb 17, 2009 at 1:58 AM, blindfold
Hi Dianne and anyone else who might care about this,
I'm a little (ok, more than a little) disappointed regarding RC33 and
the lack of communicating UI look/behavior changes to developers.
The specific reason is that RC33 seems to also have one more UI change
- Dialog titles can't be longer than
Currently the app lifecycle for the user is:
Download app - get OTA - broken app - wait for app update -
download app update - working app - get OTA - broken app - wait
for app update - download app update - working app - ..
Which is exactly why we tell developers not to use private APIs.
But
Dianne,
To finish that dreaded SlidingDrawer topic - yes the use of the
SlidingDrawer was in the Layout xml file only so I guess its was a
loophole that I end up using without realizing.
Thanks for your comments on the rest of the issues.
I think we all agree that changes in the APIs happen
Romain Guy wrote:
Please, please don't use private APIs, it only hurts the users :(
Got to admit my local doctor rarely sees people complaining about
injuries caused by private API usage, but I haven't checked with the ER
yet ;).
Al.
--
==
Funky Android Limited is registered in
Maybe an API compliance test should be run as part of any app build.
Does an API usage checking tool exist? and is it publicly available?
Al.
Jean-Baptiste Queru wrote:
Even worse, it hurts the entire ecosystem, by making users believe
that plaftorm upgrades have bugs when in fact the
That's the whole point of the SDK. It does NOT let you use private
APIs since they are stripped out of the SDK. If you compile your app
against the git tree or a custom SDK, there's not much we can do. It's
also up to the developers to be reasonable.
On Sun, Feb 8, 2009 at 1:43 AM, Al Sutton
Is checking API usage in a apk feasible? That way problems could be
picked up at distribution or installation time?
Al.
Romain Guy wrote:
That's the whole point of the SDK. It does NOT let you use private
APIs since they are stripped out of the SDK. If you compile your app
against the git
It would be way too costly to do it at install time (both in CPU and
disk space.) We could do the check during the upload to Market but
that wouldn't solve the issue with apps installed through other means
(especially alternatives to Market.) I'd rather trust the developers
to do the right thing.
That said, it could be interesting to flag bad apps on Market and
warn the user that the app he's about to download might break with a
future update of the system :))
On Sun, Feb 8, 2009 at 2:06 AM, Romain Guy romain...@google.com wrote:
It would be way too costly to do it at install time (both
I'd rather trust the developers to do the right thing.
That's probably how Microsoft felt about Windows developers before the
first virus came along.
With APK API checking at point of distribution (AndAppStore, Market,
SlideME, etc.), we could cover most user installs. I fully agree that
I'm not sure if it should be part of the sdk. any app created with the
sdk already would pass this check.
It should more be a tool built into the normal make process so you get
warnings like you get right now if you change the api.
Additionally it could notify the developer and maybe show him a
I agree it's not necessary if you're building apps with the SDK, but I
see it's primary usage as being by developers wanting to check an apks'
compliance level and its' results would be firmly tied to the android
version and thus the SDK version, so an API checker from the 1.0 SDK may
Dianne,
In this particular case, the SlidingDrawer class is not private, it
is public but it is in the
package com.android.internal.widget package. This .internal. (and
the lack of official documentation on it) is the only clue you get
that this class is probably not intended to be used
Building apps with the SDK is apparently NOT enough to insure API
compliance
as the example with the SlidingDrawer showed - the app was build with
the latest SDK
1.0 r2 and without using reflection or any other funky access.
I firmly believe that we as developers, have the most vested interest
That is a good news. May i ask a request, since you guys making a
public widget , could you provide little bit flexibility where this
widget ca attached to . For example there are cases when i want to
attach this to the top ( currently we're using custom widget based on
SlidingDrawer ). And
That is a good news. May i ask a request, since you guys making a
public widget , could you provide little bit flexibility where this
widget ca attached to .
Won't happen for cupcake.
And ability to change drawable of the handle would be
nice as well.
You already can. The handle is any
A private API does not necessarily mean the class or method has the
private Java keyword on it. Actually there are many Java-public
classes and methods that are part of the private APIs. Normally these
are stripped from the SDK. I don't know why the internal package is
still in the SDK but
too bad . shouldn't be a complicated change. well for time being i'll
continue to use that
http://code.google.com/p/android-misc-widgets/source/browse/trunk/android-misc-widgets/src/org/miscwidgets/widget/Panel.java
Any chance to see a kind of home screen container widget where you can
drop
Any chance to see a kind of home screen container widget where you can
drop your views and flip through them ? Right now we're using extended
( so now it' can accept any view(s) with in itself ) code from
workspace for that, but it'll be nice to see this sometime in the
future as official
Can you please report this issue in http://b.android.com/ ? (a plain
copy-paste will do).
Thanks,
JBQ
On Sat, Feb 7, 2009 at 6:54 AM, Stefan skyntc...@gmail.com wrote:
It appears that android.internal.widget.SlidingDrawer widget had
changed between RC30 and RC33.
On RC33 it fails to
No, SlidingDrawer is a private widget. It is not supported.
On Sat, Feb 7, 2009 at 7:18 AM, Jean-Baptiste Queru j...@android.com wrote:
Can you please report this issue in http://b.android.com/ ? (a plain
copy-paste will do).
Thanks,
JBQ
On Sat, Feb 7, 2009 at 6:54 AM, Stefan
Oh, ah, I hadn't seen that it was android.INTERNAL.SlidingDrawer
(emphasis mine).
There's no guarantee of compatibility of private APIs between versions.
JBQ
On Sat, Feb 7, 2009 at 11:28 AM, Romain Guy romain...@google.com wrote:
No, SlidingDrawer is a private widget. It is not supported.
Even worse, SlidingDrawer will move to android.widget in Cupcake :))
(And thus become public API.)
On Sat, Feb 7, 2009 at 12:14 PM, Jean-Baptiste Queru j...@android.com wrote:
Oh, ah, I hadn't seen that it was android.INTERNAL.SlidingDrawer
(emphasis mine).
There's no guarantee of
After digging a bit around in the source code, it looks like the
namespace used for the attributes of the internal widgets has
changed in RC33 from xmlns:android=http://schemas.android.com/apk/res/
android to some other namespace
(probably something like
That means your app will break in cupcake though.
Please, please don't use private APIs, it only hurts the users :(
On Feb 7, 2009 1:43 PM, Stefan skyntc...@gmail.com wrote:
After digging a bit around in the source code, it looks like the
namespace used for the attributes of the internal
Even worse, it hurts the entire ecosystem, by making users believe
that plaftorm upgrades have bugs when in fact the applications are
broken to start with.
JBQ
On Sat, Feb 7, 2009 at 3:18 PM, Romain Guy romain...@google.com wrote:
That means your app will break in cupcake though.
Please,
Yes, I do agree that relying on private APIs is dangerous and should
be avoided for all the reasons you mention.
(The only reason I posted my findings is to save somebody the
debugging time as it was not obvious what was the reason at first)
This brings another related question. Is there a
When a new SDK is posted, there is a complete API diff and overview of the
changes. However, there is very little change to the platform APIs in 1.1,
so there isn't much to say about this one. I'm not sure when an SDK for it
will be available.
Also, out of curiosity, how did you go about using
30 matches
Mail list logo
