Look at the console when debugging this in the simulator. You would
probably see exceptions indicating you can't add a component to a Container
if it's already added to some container (even if it's the same container).
Yes, you need to adapt the code to handle that logic. Orientation change
re-layout needs to be slightly different from first showing of the UI. I'd
also recommend an animation on orientation change which is something we
don't need/want for the first showing of the form.
On Thursday, September 17, 2020 at 12:07:41 PM UTC+3 P5music wrote:
> I created a method like the one you can see below. It is called at startup
> and it works. It is also called in the orientation change listener.
>
> But when the orientation changes I see that the user interface is cleaned
> up and no containers appear, that is, the new rotated interface does not
> appear, does not form, it is blank.
> If there is no call to the remove() methods I get errors like "already
> added", and it is reasonable because the containers don't get removed.
> So the right version has to include the remove() calls.
>
> Hence, I think the code is adding the right containers as it happens at
> startup but the user interface is not shown. Why?
>
> private void setContainersAndForm()
> {
> editingContainer.remove();
> itemListContainer.remove();
> fab.remove();
>
> if (isPortrait() && (editingConditions))
> {
> new
> EditingForm(appData,myData,mainForm,editingContainer,otherParameters).show();
> setEditor();
>
> if (isPortrait() && !(editingConditions)
> {
> removeContainers();
>
> mainForm.add(tl.createConstraint().heightPercentage(100).widthPercentage((int)(1*100)),fab.bindFabToContainer(masterContainer));
> }
>
> if(isTablet() && !isPortrait() )
> {
>
> removeContainers();
> ((EditingContainer)editingContainer).setCallingForm(mainForm);
>
> mainForm.add(tl.createConstraint().heightPercentage(100).widthPercentage((int)(leftContainerRatio*100)),fab.bindFabToContainer(masterContainer))
> .add( editingContainer);
> if (editingConditions) setEditor();
>
> }
>
> // also with these two lines
> //mainEditingContainer.revalidate();
> //itemListContainer.revalidate();
>
> mainForm.revalidate();
> }
>
> Il giorno giovedì 17 settembre 2020 alle 06:15:49 UTC+2 Shai Almog ha
> scritto:
>
>> Look sat the code for kitchen sink. Notice we encapsulate each demo in a
>> Demo class. Then in the main KitchenSink class we show either a Form or a
>> Container based on the mode (tablet or phone). Yes it's pretty similar to
>> this.
>>
>> On Wednesday, September 16, 2020 at 9:54:57 AM UTC+3 P5music wrote:
>>
>>> What you say seems to be merging the two things, like I am already
>>> doing? Indeed my app is for tablet and phone, so my question was just about
>>> the management of these two scenarios, and the orientation too.
>>>
>>> Is this what you are advicing?
>>>
>>> if (isPortrait() && (editingConditions))
>>> {
>>> new
>>> EditingForm(appData,myData,mainForm,editingContainer,otherParameters).show();
>>> setEditor();
>>>
>>> if (isPortrait() && !(editingConditions)
>>> {
>>> removeContainers();
>>>
>>> mainForm.add(tl.createConstraint().heightPercentage(100).widthPercentage((int)(1*100)),fab.bindFabToContainer(masterContainer));
>>> }
>>>
>>> if(isTablet() && !isPortrait() )
>>> {
>>>
>>> removeContainers();
>>>
>>> ((EditingContainer)editingContainer).setCallingForm(mainForm);
>>>
>>> mainForm.add(tl.createConstraint().heightPercentage(100).widthPercentage((int)(leftContainerRatio*100)),fab.bindFabToContainer(masterContainer))
>>> .add( editingContainer);
>>> if (editingConditions) setEditor();
>>>
>>> }
>>>
>>> Thanks in advance
>>> Il giorno mercoledì 16 settembre 2020 alle 04:40:29 UTC+2 Shai Almog ha
>>> scritto:
>>>
>>>> My advice is to use Containers for everything but have global
>>>> navigation logic. So when you need to show a UI element you can invoke
>>>> that
>>>> single place that decides.
>>>>
>>>> If this is on a phone you would create a Form add the container to it
>>>> and set its title etc. then show.
>>>> If this is a tablet you would replace the last container.and update the
>>>> subtitle in the UI
>>>>
>>>> On Tuesday, September 15, 2020 at 10:39:40 AM UTC+3 P5music wrote:
>>>>
>>>>> So your advice is to use one form for the master/detai in every
>>>>> configuration, just managing the container, with the override of the back
>>>>> button and using the back command to manage the container inside the form.
>>>>> So I have not to do this:
>>>>>
>>>>> if (isPortrait() && (*conditionsAreTrue*))
>>>>> {
>>>>> new EditingForm(appData,myData,mainForm,editingContainer,other
>>>>> parameters).show();
>>>>> }
>>>>> (this is what I am trying to do now)
>>>>>
>>>>> the form will be just used when a new screen has to be presented, like
>>>>> the help form.
>>>>> Is it right?
>>>>>
>>>>> Il giorno martedì 15 settembre 2020 alle 03:50:41 UTC+2 Shai Almog ha
>>>>> scritto:
>>>>>
>>>>>> You can use setBackCommand and override the hardware back command to
>>>>>> have any functionality you want. It can just replace containers and then
>>>>>> eventually move a form. You obviously need to keep track of everything
>>>>>> which isn't simple.
>>>>>>
>>>>>> On Tuesday, September 15, 2020 at 12:48:15 AM UTC+3 P5music wrote:
>>>>>>
>>>>>>> My app needs to manage cases where a back navigation occurs but not
>>>>>>> toward the original master/detail form, indeed to a different
>>>>>>> orientation
>>>>>>> of the editing view itself.
>>>>>>> For example the editing view in portrait mode is fullscreen and can
>>>>>>> undergo a device rotation: in that case the landscape mode is the new
>>>>>>> full
>>>>>>> screen mode for the editing view, while master/detail is reached back
>>>>>>> only
>>>>>>> when further back navigation occurs when the user tap the back button.
>>>>>>>
>>>>>>> So I thought this has to be accompished with a new form: the editing
>>>>>>> form, to which the editing container is added, because I think it is
>>>>>>> the
>>>>>>> right way to manage back navigation, that is. navigation is between
>>>>>>> forms,
>>>>>>> back and forth.
>>>>>>>
>>>>>>> I ask whether the editing container has to be recreated, or it can
>>>>>>> removed from the master/detail form and then added to the editing form.
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>>> Il giorno domenica 13 settembre 2020 alle 03:43:59 UTC+2 Shai Almog
>>>>>>> ha scritto:
>>>>>>>
>>>>>>>> I mean having containers side by side in one form (see the kitchen
>>>>>>>> sink where we do just that).
>>>>>>>> I don''t recommend having a form embedded in a form. Forms are very
>>>>>>>> "heavy" and things sometimes fail when you add a form inside another
>>>>>>>> form.
>>>>>>>> Historically this was prohibited (we'd throw an exception in that
>>>>>>>> case) but
>>>>>>>> some use cases for embedding a form do exist. I'd still avoid it when
>>>>>>>> possible.
>>>>>>>>
>>>>>>>> On Saturday, September 12, 2020 at 12:31:31 PM UTC+3 P5music wrote:
>>>>>>>>
>>>>>>>>> Thanks, do you mean having two forms side by side, that expands
>>>>>>>>> when in portrait mode going full screen singularly, or you mean that
>>>>>>>>> I open
>>>>>>>>> another form on top of the main form?
>>>>>>>>> I started creating an editing container that can be added to the
>>>>>>>>> main form or to the editing form, so I remove all and then add again.
>>>>>>>>> Is
>>>>>>>>> this the right way to do that?
>>>>>>>>>
>>>>>>>>> Il giorno sabato 12 settembre 2020 alle 07:04:13 UTC+2 Shai Almog
>>>>>>>>> ha scritto:
>>>>>>>>>
>>>>>>>>>> In some cases you need two forms and in some cases two
>>>>>>>>>> containers.
>>>>>>>>>> The trick for doing this is to work with two containers and when
>>>>>>>>>> necessary wrap them in a Form to enable the two page master detail.
>>>>>>>>>>
>>>>>>>>>> On Friday, September 11, 2020 at 3:41:56 PM UTC+3 P5music wrote:
>>>>>>>>>>
>>>>>>>>>>> My Codename app has master/detail layout.
>>>>>>>>>>> According to orientation the detail (editing) or the master can
>>>>>>>>>>> stay full screen.
>>>>>>>>>>> I have to handle many orientation and editing status
>>>>>>>>>>> configurations, so sometimes the editing screen will be displayed
>>>>>>>>>>> out of
>>>>>>>>>>> the master screen in portrait orientation.
>>>>>>>>>>>
>>>>>>>>>>> The back navigation (button and other gestures) has to be
>>>>>>>>>>> managed in both cases.
>>>>>>>>>>>
>>>>>>>>>>> I am not sure if I have to use a main form and two containers,
>>>>>>>>>>> or instead two forms, that is, also an EditingForm with the
>>>>>>>>>>> EditingContainer inside.
>>>>>>>>>>> Thanks in advance
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
--
You received this message because you are subscribed to the Google Groups
"CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/codenameone-discussions/fbb28dd5-aec3-4f7c-bae3-9de98436da92n%40googlegroups.com.
