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 codenameone-discussions+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/codenameone-discussions/a09bd518-169d-44c7-bd1b-e4cc8b603570n%40googlegroups.com.
