Re: [android-developers] Re: Dev Environment - maven-android-eclipse

2012-03-22 Thread Michael Sims
Android + Maven + Eclipse is definitely possible, but speaking from
experience, it's painful.  Tedious to get working, builds are very
very slow and fragile.  You can do it, but it'll hurt.

For what it's worth, IntelliJ + Android + Maven works wonderfully.
Because I was working on a largish Android app that was built with
Maven, I switched to IntelliJ CE and I've been a very happy camper
since then.  Everything supported out of the box (no plugins to
install), everything cooperates, and the build is fast and stable.
Switching IDEs is a big deal though, but if you really like Maven, I
personally believe that is your best option

On Thu, Mar 22, 2012 at 10:09 AM, b0b pujos.mich...@gmail.com wrote:


 On Thursday, 22 March 2012 15:55:43 UTC+1, Ricardo Gladwell wrote:

 Hi Ted

 This is possible, please see the Android Connector for M2E (Maven for
 Eclipse):

 http://rgladwell.github.com/m2e-android/

 Regards...



 The thing is that it never worked too well as the eclipse ADT plugin and
 m2e-android / maven-android-plugin conflict with each other.
 Each one expect a specific directory layout for example
 Add to that the fact ADT is an ever moving target which makes playing nice
 with each other difficult...
 And it is very badly documented...
 I'm successuflly using maven in Android Library projects to manage pure Java
 depencies. Forget it in your main Android project though or expect a
 headache.
 m2e-android can probably work without the ADT eclipse plugin though. Never
 tried it but you loose some of the advantage of the ADT plugin.



 --
 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-developers+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en

-- 
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en


[android-developers] Re: Views inside a custom ViewGroup not rendering after a size change

2011-05-03 Thread Michael Sims
For the benefit of the archives, I asked the same question on Stack Overflow
and it was answered by Romain Guy:

http://stackoverflow.com/questions/5852758/views-inside-a-custom-viewgroup-not-rendering-after-a-size-change

On Sun, May 1, 2011 at 8:19 PM, Michael Sims michael.h.s...@gmail.comwrote:

 I'm running into a problem that occurs when the containing FrameLayout is
 resized.  The current implementation removes all of the views that represent
 the events and attempts to add new ones and calculate their sizes based on
 the current size of the FrameLayout.  This work is being triggered via the
 onSizeChanged() method of View which is overridden in the FrameLayout.

 When the view is resized, this code is executed and the views are updated,
 however, none of them actually render on the screen... the views contained
 within the FrameLayout are simply not visible.  If I load the view in the
 hierarchyviewer tool, they are part of the view tree, and are outlined in
 the overview in the positions they should be in, but they do not display.
 (Note that the views are visible on the initial render of the FrameLayout...
 it's only after a resize that they disappear.)


-- 
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Views inside a custom ViewGroup not rendering after a size change

2011-05-02 Thread Michael Sims
   Hi all,


I'm running into a problem that has me stumped and I was hoping someone
could give me some pointers.


I'm working on an application that uses a custom ViewGroup (actually a
FrameLayout that contains a RelativeLayout) to render an event calendar.
The events inside the calendar are represented as views that are sized
according to the duration of the event and the size of the containing view.


I'm running into a problem that occurs when the containing FrameLayout is
resized.  The current implementation removes all of the views that represent
the events and attempts to add new ones and calculate their sizes based on
the current size of the FrameLayout.  This work is being triggered via the
onSizeChanged() method of View which is overridden in the FrameLayout.


When the view is resized, this code is executed and the views are updated,
however, none of them actually render on the screen... the views contained
within the FrameLayout are simply not visible.  If I load the view in the
hierarchyviewer tool, they are part of the view tree, and are outlined in
the overview in the positions they should be in, but they do not display.
(Note that the views are visible on the initial render of the FrameLayout...
it's only after a resize that they disappear.)


It appears that the order of events during the resize is as follows:

onMeasure()

onMeasure()

onSizeChanged()

onLayout()


Calling requestLayout() after resetting the views (inside onSizeChanged())
seems to have no effect.  However, if I cause some delay before calling
requestLayout(), the views become visible.  I can cause this delay by
spawning a thread and sleeping, or by creating a dummy button that simply
calls requestLayout() and pressing it after the resize myself, or even this
ugly hack placed at the end of onSizeChanged():


post(new Runnable() {

public void run() {

requestLayout();

}

});


When I use this hack, the contained views are visible, and the order of
events is as follows:

onMeasure()

onMeasure()

onSizeChanged()

onLayout()

onMeasure()

onMeasure()

onLayout()


So it appears that forcing a second measure pass (after the view tree has
been modified) makes the contained views visible as they should be.  Why
delaying the call to requestLayout() does this is a mystery to me.


Can anyone provide any pointers as to what I'm doing wrong?


I realize that this is somewhat difficult to follow without looking at some
code, so I have created a small sample application that exhibits my issue
and made it available on Github:

https://github.com/MichaelSims/ViewGroupResizeTest


The hack I mentioned above is committed to a separate branch:

https://github.com/MichaelSims/ViewGroupResizeTest/tree/post-runnable-hack


If I can provide any additional information, please let me know and thanks
in advance.

-- 
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en