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/a09bd518-169d-44c7-bd1b-e4cc8b603570n%40googlegroups.com.
