> I mean allowing the user to dynamically change the size of the open drawer.
> Right now, when you let go, it either springs open or shut.
Ah, misunderstood you then.
Since there's no 'amount open' callback in the API I guess it's not
intended to remain in a partial state, you would have to chan
On Friday, March 22, 2013 12:38:05 AM UTC-7, Pent wrote:
>
> > Has anyone figured out how to make it open partially - ie not snap open
> all
> > the way?
>
> I implemented that a few years ago, looking at the layout seems like
> the height of the SlidingDrawer view is the limited.
>
I don't
> Has anyone figured out how to make it open partially - ie not snap open all
> the way?
I implemented that a few years ago, looking at the layout seems like
the height of the SlidingDrawer view is the limited.
Pent
--
--
You received this message because you are subscribed to the Google
Group
Hi Paul,
Any success on this? I am facing same issue.
Regards
--
--
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
androi
android:paddingBottom="16dp"... in you listview will do the trick. Set it
to whatever dp you require
On Saturday, October 1, 2011 12:04:12 PM UTC+1, charlie babitt wrote:
>
> Hallo!
>
> In my activity I have a list view and I want to have a sliding drawer
> at the bottom of the screen. The hand
try setting on the SlidingDrawer android:layout_alignParentBottom="true".
--
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
http://developer.android.com/guide/practices/screens_support.html
On 24 jan, 08:42, joaocruz04 wrote:
> Hi,
>
> i'm having a problem:
>
> i've created a sliding drawer with a specific height, at the bottom of
> the screen.
> The problem is, when the height of the SlidingDrawer is set as
> "fill_p
Let your top level layout be a RelativeLayout or FrameLayout -- these
each permit multiple views to be in the same position. Let the
SlidingDrawer be a direct child of your top level layout.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
T
Hi,
I think it will help you.
check this link
http://www.androidpeople.com/android-sliding-drawer-example-tutorial/
On Feb 11, 12:48 am, Salsero69 wrote:
> How do I get the sliding drawer to open over the existing layout. I'm
> having a hard time finding an example and having no luck figuring
It looks like you have to dig a little deeper. The images and the
layout referencing them are in the Launcher package, which is open
source.
http://android.git.kernel.org/?p=platform/packages/apps/Launcher.git;a=blob;f=res/layout-land/launcher.xml
On Sun, Apr 18, 2010 at 12:04 PM, Pinheiro wrote
Thanks, Bob!
Unfortunately, it seems Launcher's handle is not accessible (at least
it's not in the SDK).
Bummer, will have to reinvent the wheel and make my own :-(
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group,
It's a quick question you should be asking yourself. More useful than
doing it for you, I'll tell you how.
Go to your SDK. In the platforms directory, choose your platform
version. Inside there is a data directory, and inside that is the
system's res directory.
Go into the drawables/ directory (m
The same with me. Just filed a bug report at
http://code.google.com/p/android/issues/detail?id=3162
You can go there and star the issue to get notified on changes.
wbr,
Brian
On 19 Mai, 14:47, brindy wrote:
> Yep, exactly the same here. =)
>
> Cheers,
> Brindy
>
> On May 7, 11:27 am, cannehal
Yep, exactly the same here. =)
Cheers,
Brindy
On May 7, 11:27 am, cannehal wrote:
> As I said before I have the same issue as Sheepz. It works fine in
> runtime, but in layout editor in eclipse there is Exception. For me it
> looks like a bug in plugin.
> And for forthcoming questions: I am us
Hi All,
I am able to do that.. But i can not place the SlidingDrawer at
the top.
It is coming bottom/right.
Please help me in this regards...
Thanks
On May 12, 9:51 am, JITU wrote:
> Hi All,
>
> I am new to android.I need some help regarding Slidingdrawer which is
> included with SDK 1.5
As I said before I have the same issue as Sheepz. It works fine in
runtime, but in layout editor in eclipse there is Exception. For me it
looks like a bug in plugin.
And for forthcoming questions: I am using latest SDK (1.5) and proper
eclipse plugin.
On May 6, 1:34 am, Sheepz wrote:
> if you m
if you mean 1.5, yes i am, i have also updated the editors for eclipse
as described in the upgrade sdk page.
On May 5, 7:06 pm, dan raaka wrote:
> are you using the latest version of SDK ?
>
> On Tue, May 5, 2009 at 4:04 PM, Sheepz wrote:
>
> > I took a look at the api
> >http://developer.andr
are you using the latest version of SDK ?
On Tue, May 5, 2009 at 4:04 PM, Sheepz wrote:
>
> I took a look at the api
> http://developer.android.com/reference/android/widget/SlidingDrawer.html
> and copied their example to a clean sandbox project
> this is the code:
> [beginquote]
>
>
> http://s
I took a look at the api
http://developer.android.com/reference/android/widget/SlidingDrawer.html
and copied their example to a clean sandbox project
this is the code:
[beginquote]
http://schemas.android.com/apk/res/
android"
android:orientation="vertical"
android:layout_width="fill_pare
take a look at the Launcher source code in the open source
./packages/app/Launcher
That should serve as a good example as to how to use it ..
-Dan
On Fri, May 1, 2009 at 8:29 PM, Sheepz wrote:
>
> anyone found a solution?
>
> On May 1, 10:03 am, cannehal wrote:
> > I tkink I have the same issu
anyone found a solution?
On May 1, 10:03 am, cannehal wrote:
> I tkink I have the same issue. For handle I have ImageView and for
> content I am using LinearLayout with some views inside of it.
> There is probably problem with eclipse plugin because in runtime it
> works fine.
>
> On May 1, 7:01
I tkink I have the same issue. For handle I have ImageView and for
content I am using LinearLayout with some views inside of it.
There is probably problem with eclipse plugin because in runtime it
works fine.
On May 1, 7:01 am, Sheepz wrote:
> anyone else found something here?
>
> On Apr 30, 5:
I tkink I have the same issue. For handle I have ImageView and for
content I am using LinearLayout with some views inside of it.
There is probably problem with eclipse plugin because in runtime it
works fine.
On May 1, 7:01 am, Sheepz wrote:
> anyone else found something here?
>
> On Apr 30, 5:
anyone else found something here?
On Apr 30, 5:43 pm, Sheepz wrote:
> okay, that didnt work :(
> android:layout_width="wrap_content"
> android:layout_height="wrap_content" android:handle="@+id/ImageView01"
> android:content="@+id/ImageView02">
> android:layout_width="wrap_content"
> android:la
okay, that didnt work :(
still getting the same message in the ADT only now when launching the
app, it simply stalls half drawn instead of giving an error message
saying the application threw an exception...
On Apr 30, 5:40 pm, Romain Guy wrote:
> You must use different views, it doesn't ma
You must use different views, it doesn't make sense to have the same
view, it's going to confuse SlidingDrawer :)
On Thu, Apr 30, 2009 at 2:38 PM, Sheepz wrote:
>
> yeah, i figured that might be it, but even after this fix:
> android:layout_width="wrap_content"
> android:layout_height="wrap_con
yeah, i figured that might be it, but even after this fix:
i still get the same error - i'm gonna try using diffrent views for
the content and the handle
brb :)
On Apr 30, 5:32 pm, Romain Guy wrote:
> There is a bug indeed, the exception message says the "handle" is
> missing, but the "conten
There is a bug indeed, the exception message says the "handle" is
missing, but the "content" is missing. Check out the javadoc. I'll fix
the exception message.
On Thu, Apr 30, 2009 at 2:26 PM, Sheepz wrote:
>
> okay, i might be missing something, the reason i think that this is a
> bug is that i
okay, i might be missing something, the reason i think that this is a
bug is that if you use the supplied tool, and cannot avoid getting an
exception - it's a bug...
i don't see any way around it - the way to create this widget is:
a) create widget
b) get exception
c) fix error
d) populate it with
It *needs* a handle. It's not a bug, it's a requirement to make the widget work.
On Thu, Apr 30, 2009 at 2:16 PM, Sheepz wrote:
>
> so you mean i have to put some content in it and only then it will be
> visilble? even if this is true, it's still a bug - albeit with a much
> lower severity...
>
Do what the exception says:
"java.lang.IllegalArgumentException: The handle attribute is required
and must refer to a valid child."
You need to define the widget to use as the handle of the drawer.
On Thu, Apr 30, 2009 at 2:02 PM, Sheepz wrote:
>
> when adding a slidingDrawer object to my appl
so you mean i have to put some content in it and only then it will be
visilble? even if this is true, it's still a bug - albeit with a much
lower severity...
i'll check it out and report back in a few.
On Apr 30, 5:10 pm, Romain Guy wrote:
> Do what the exception says:
>
> "java.lang.IllegalArgu
i forgot to mention that i take the reference code from Launcher
however i didnt find SlidingDrawer doesnt call any makeMeasureSpec
so neither did i
but i encountered RuntimeException in my case
so am i doing some wrong with SlidingDrawer?
thanks
On Apr 30, 3:43 pm, allstars wrote:
> hi
> i woul
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
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 any
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 and
>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 privat
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
On Sun, Feb 8, 2009 at 6:02 AM, Stefan wrote:
> 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 have to sa
> 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 offici
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 your
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 indee
> 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 an
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 abilit
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
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 d
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
generate
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
Looks like we're on the same page :).
Just PLEASE make this a public API checker (possibly as part of the
SDK). I'd happily include the check into AndAppStore, and I'm sure Shane
would be interested in putting into SlideME as well.
Al.
Romain Guy wrote:
> That said, it could be interesting to
"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
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 wrote:
> It would be way too costly to do it at install time (both in CPU and
> disk
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.
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
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 wro
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 appli
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 Eng
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 t
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 singl
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 wrote:
> That means your app will break in cupcake though.
>
> Please, please don't use priv
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" wrote:
After digging a bit around in the source code, it looks like the
namespace used for the attributes of the "internal" widgets has
changed i
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 http://schemas.android.com/apk/res/andr
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 wrote:
>
> Oh, ah, I hadn't seen that it was android.INTERNAL.SlidingDrawer
> (emphasis mine).
>
> There's no guarantee of compatibility of priv
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 wrote:
>
> No, SlidingDrawer is a private widget. It is not supported.
>
> On Sat, Feb 7, 20
No, SlidingDrawer is a private widget. It is not supported.
On Sat, Feb 7, 2009 at 7:18 AM, Jean-Baptiste Queru 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 wrote:
>>
>> It app
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 wrote:
>
> It appears that android.internal.widget.SlidingDrawer widget had
> changed between RC30 and RC33.
>
> On RC33 it fails to inflate the layout X
65 matches
Mail list logo
